| Table of Contents | ||||
|---|---|---|---|---|
|
Configuration in Jira
This page deals with the configuration on SAP side, for Jira side please refer to the following page: JIRA - Solution Manager V1
...
The CC4 Solution can be setup in SAP, either by following the guidance of the confluence documentation below or by following the guidance of the SAP IMG guide - CC4 Connector.
| Info |
|---|
Note: As the CC4 Connector IMG guide is still in the development phase and has only been partially released, there might be some missing setup activities. The confluence guided documentation can help you with the missing steps while its been fully released. |
RFC Creation
Please follow the steps outlined here to create a stable connection between your systemsRFC Connectivity
...
Activation of oData-Service
Open transaction /n/IWFND/MAINT_SERVICE and search for the oData-Service /XALM/CC4_EXT_INTEG_CREATE_SRV_01 and activate the Standard ICF Node
...
The shipped transport mentioned above introduces a view cluster that serves as mapping table for all synchronization calls.
Open transaction SM34 and open view cluster /XALM/CC4_SFM_VC.
...
In section Field Definition you find a collection of all JSON keys that are used by the interface. As specified in the Jira configuration section for this template some of these are purpose bound and can therefore not be mapped freely.
Currently it is not possible to send data with JSON keys deviating from this list:
JSON field | Note |
|---|---|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| only available SAP inbound |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| only available SAP inbound |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|
...
Process Types
Here you can specify what process types should be synchronized.
...
Object Key | Description | Notable Examples |
|---|---|---|
| Standard SAP Header fields | Title |
| Customer Fields | any custom field |
| Standard SAP Activity fields | Priority |
| Status | Status |
| Text types | Description (long) |
| Partner Functions | Creator |
| Service Process | Long Description (up to 120 character) |
| Sales | External Reference |
| Service Request Header Fields | Urgency, Impact |
| Categories | Category 1-4 |
Mandatory - Status
JSON key IVSTATUS has to be mapped with object STATUS
...
Option 1: Using Standard Description
JSON key IVTITLEhas to be mapped to object ORDERADM_H with field in object structure DESCRIPTION
...
Option 2: Using Standard Long Description (up to 120 characters)
JSON key IVTITLEhas to be mapped to object SERVICE_H with field in object structure /AICRM/DESC_L
...
Example - Text Type
JSON key IVASSUMPTION has been mapped to object TEXT with logical key CD03 (Text-ID in SAP to be used) and field in object structure can be maintained as FULL or LAST, by default LAST is used.
...
Example - Partner Field
JSON key IVOWNERUSER has been mapped to object PARTNER with logical key SMCD0001 and field in object structure can be maintained as either USER, PARTNER or EMAIL. If field is not specified the inbound call tries to determine in the background which type of data is send and the outbound call sends by default the PARTNER.
...
Example - Custom field to anything else
JSON key IVLOCAL has been mapped to object CUSTOMER_H with field in object structure ZZFLD00000W.
...
Example - Predecessor ID
If you want to create a ticket based on a template, e.g. Change Request, this can be realized by mapping the JSON key IVPREDECESSORID to the object DOC_FLOW with the logical key E.
Otherwise no custimizing for the predecessor Id is required.
...
Example - Multilevel Category
If you have a Solution Manager Change using more than one Multi-Level Category scheme and both need to be mapped, it can be realized by a mapping in the following way.
To map both category one JSON key has to be mapped for each category, e.g. IVCATEGORY and IVCUSTOM01. Both field have to be mapped with the object SUBJECT and the logical key receives the value of the technical ID of the catalog type for the category scheme, e.g. C or D.
...
Value Mapping
Some fields can be further customized in this section.
...
These values specified for external status is sent to Solution Manager. If the status is already in a format that SolMan expects (i.e. “E????”) introducing further mapping here is not necessary.
However this grants the option to send arbitrary status keys from Jira and instead shift the mapping to SolMan.
Example - Multilevel Category
Depending on which Jira field is selected to send information for the category, the value mapping can be used to map the value to the Solution Manager internal Category ID. In the following example the category is mapped to the JSON field IVCATEGORY.
...
If the SolMan Category ID is already maintained in the Jira field and send, then introducing further mapping here is not necessary.
Example - Predecessor ID
This field should only be used when a predecessor document is present of the process type that you are synchronizing (i.e. a Request for Change for a Normal Change, or a Change Cycle for a Request of Change).
As mentioned in the Jira side configuration it is possible to inform a predecessor Id via field mapping that maps a created SolMan Solution Mananger ticket to a specified predecessor document.
...
Selecting the empty process type the following mapping is added in the view ‘Value Mapping’. Using the JSON key IVPROCESSTYPE the value whichshould by default be used can be specified. The Internal Value represents the default process type, if no value is handed over.
...
The shipped transport mentioned above introduces two SOCM actions that can be used
SOCM Action | Function |
|---|---|
| Sends out a call to Jira that triggers the creation of a Jira ticket. If there is already an external ticket linked to the document triggering this call an update call is sent instead. |
| Sends out a call to Jira that updates the connected Jira ticket. This call synchronizes status and field values between the tickets. If there is no linked ticket at the time of execution no ticket will be created. |
...
You can access SOCM action mapping via the following path in SPRO or by accessing the maintenance cluster directly.
...
In case of any error has occurred during the synchronization, the status icon will be red in color and the processing log gives the information about the error.
Also, the field ‘Direction’ ‘Direction’ helps to Identify whether the synchronization was inbound or outbound.
...
The SLG1 Cross Connector log provides detailed information about the Processing of the Cross connectorConnector.
...
It helps to see, which fields and data have arrived as inbound payload and outbound payload.
...
The SLG1 Cross Connector Logging can be activated by adding the parameter key ‘/XALM/CC4_ACTIVATE_LOG' and value 'X’ X' in the AGS_WORK_CUSTOM table.
Steps to add the entry in the AGS_WORK_CUSTOM table
Go to SM30 transaction and open ‘AGS'AGS_WORK_CUSTOM’CUSTOM'
...
and enter the parameter key and parameter value as below.
...
The SLG1 Cross Connector Log can be seen, using the object ‘/XALM/CC4’CC4.