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

Configuration in SAP

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.

RFC Creation

Please follow the steps outlined here to create a stable connection between your systemsRFC Connectivity

Note down the name of the RFC connection created here as we will use it later.

Synchronization User

Create a user in Solution Manager that will be used for executing incoming synchronization calls.

Authorization data of this user needs to be maintained on Jira side, please refer to 1.1 Connection Profile

Import of Transport Requests

The template Solution Manager V1 uses an oData-Service developed by CrossALM that is utilized to handle incoming and outgoing calls from and to Jira.

Please import the SAP Transport Requests provided to you after reaching out to https://crossalm2.atlassian.net/servicedesk/customer/portal/6 these include the oData Services necessary to continue with the configuration.

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

Add LOCAL_SM as System Alias.

Connection Mapping

Please maintain an entry for External System GUID in external requirement configuration as described here

SAP - Focused Build Business Requirement (Standard)

Content Mapping via view cluster Maintenance

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 this screenshot you see multiple configuration profiles that have been defined. The shipped transport includes one example configuration profile that can server as guidance.

Action

Please make sure that the RFC Destination maintained here is equal to the name you have specified.

The remaining data under this node should not be altered as it might cause the oData-Service to stop working.

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:

Process Types

Here you can specify what process types should be synchronized.

By default the shipped transport includes some sample mappings.

Field Mapping

Here you specify the mapping configuration for specific fields.

The following object types can be mapped

Mandatory - Status

JSON key IVSTATUS has to be mapped with object STATUS

Mandatory - Title

Option 1: Using Standard Description

JSON key IVTITLE has 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 IVTITLE has 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.

• FULL: send all texts of the specified type (in logical key) to Jira

• LAST: send last text of the specified type (in logical key) to Jira

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.

• USER: system user name

• PARTNER: Business Partner of the user

• EMAIL: e-mail of the user which is used to determine the business 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 Template, this can be realized by mapping the JSON key IVPREDECESSORID to the object DOC_FLOW with the logical key E.

Otherwise, if a predecessor is mapped, no customizing 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 fields 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.

Example - Status

On Jira side you can configure what status is being sent out when a certain transition is triggered

This is explained in further detail here: 3.1 Status Mapping

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.

Keep in mind that only a 1:1 mapping of external to internal category value is possible.

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 Solution Mananger ticket to a specified predecessor document.

It is also possible to maintain a “fallback” predecessor Id in case no value is being sent that will automatically assign a predecessor document.

Example - Process Type

This field should only be used when the process type is not handed over by Jira due to customizing. In this case a default value for the process type has to be maintained.

To map the process type default value, first in the view ‘Process Types’ an entry with an empty process type has to be maintained.

Option A: Process Type is send empty

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.

Option B: Another Value is send as Process Type

As in option A add a value mapping to the empty process type. Then the internal value is the process type to be used and the external value is the incoming value from Jira which is different from the SAP Process type.

Triggering the synchronization

In order to specify when information should be sent from Solution Manager to Jira we need to specify and maintain the triggers to send out information.

The shipped transport mentioned above introduces two SOCM actions that can be used

This action can be triggered in multiple different ways of which we are going to recommend the following:

Via SOCM Action Profile

You can access SOCM action mapping via the following path in SPRO or by accessing the maintenance cluster directly.

This has the benefit of reduced customizing effort but the limitation of only triggering on status change.

Example Implementation

The implementation below triggers the creation of a Jira ticket at the same time as the Solution Manager document is created. As well as sending a status update on every other status.

E0001 is mapped to /XALM/CC4_CR

E0?? is mapped to /XALM/CC4_UP

Keep in mind that in addition to assigning the action to the technical status, the execution time of the action has to be specified as well.

Via PPF Action

The specified SOCM actions can also be called via PPF action.

This option has the added benefit of freely choosing the execution time of the outbound update but requires more effort to set up.

Open administration of ppf actions via transaction SPPFCADM and navigate to the action of the process type you want to synchronize.

Manual trigger in dialog

Create an action definition with your preferred description

Make sure the action is displayed in toolbox

PPF action should use method HF_EXECUTE_ACTION and then trigger either /XALM/CC4_CR or /XALM/CC4_UP as specified above.

Schedule the action to show up in your desired status. Here we specified the action to be available in every status.

Do not define a Start condition as this action is triggered manually.

The result is that the action is available in Web UI and can be triggered manually.

Trigger on status change

Define a ppf action with your desired description.

This time schedule the action automatically.

PPF action should use method HF_EXECUTE_ACTION and then trigger either /XALM/CC4_CR or /XALM/CC4_UP as specified above.

Maintain a schedule condition. Here we specified the action to be scheduled in every status.

Define a start condition to trigger the ppf action specific to your use case.

Web UI Configuration

The shipped transport mentioned above introduces two additional UI Assignment blocks that can be added to the UI configuration of the process type you are syncing.

Cross Connector Assignment Block

It provides an overview of the system the ticket has been synced to as well as a jump in URL to the linked ticket in Jira.

Cross Connector Synchronization Log Assignment Block

It provides a status overview of each synchronization of the ticket. It helps in understanding whether a synchronization was inbound or outbound and whether it was successful or not at a particular date and time.

Troubleshooting

Troubleshooting via Cross Connector Synchronization Log Assignment Block

The Cross Connector synchronization log provides an overview of all the synchronizations of the ticket which happened on a particular date and time.
It helps to easily identify whether the synchronization was successful or if an error occurred.

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’ helps to identify whether the synchronization was inbound or outbound.

Troubleshooting via SLG1 Log

The SLG1 Cross Connector log provides detailed information about the Processing of the Cross Connector.

It helps to see, which fields and data have arrived as inbound payload and outbound payload.

It also shows the detailed step-by-step processing data of the cross connector, like field and value mapping, or if any error occurred during the processing or whether it was processed fine.

How to activate the SLG1 Cross Connector Log?

The SLG1 Cross Connector Logging can be activated by adding the parameter key /XALM/CC4_ACTIVATE_LOG and value '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_WORK_CUSTOM'

and enter the parameter key and parameter value as below.

How to view the SLG1 Cross Connector Log?

The SLG1 Cross Connector Log can be seen, using the object /XALM/CC4.