SOCM & PPF actions

Introduction

In order to specify when information should be sent from Solution Manager to the external tool (e.g. Jira) we need to specify and maintain the triggers to send out information.

The following chapters and sections will explain you how to configure this send actions.

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 without any start conditions and without any parameters.

Open

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.

Open

implementation using Cloud action

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 and parameters of the synchronization call 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. Alternatively you navigate there using SPRO:

Manual trigger in dialog

Create an ppf action definition with your preferred description

Make sure the action is displayed in toolbox

Alternatively, for CC4 Server, the PPF action should use method HF_EXECUTE_ACTION and then trigger either /XALM/CC4_CR or /XALM/CC4_UP.

You need to schedule the action to show up only in your desired status. Here we specified the action to be available in every status.

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.

Maintain a schedule condition if you want to use it in desired status only. 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.

Important hints

• Please ensure that the “Sort Order for Display” is higher than the sort order of the ppf action triggering the status change. We reccommend to set the sort order to “9999”.

• If the status change is getting triggered by another ppf action on save, the schedule condition can be the previous status and the start condition can be the new/current status. (ChaRM scenario)

• If the status change is getting triggered by a dropdown box, schedule or/and start condition have to be the current/new status. You can detect a status change by using the container parameter STATUS_CHANGE. (ITSM scenario)

Additional hints and optional configuration steps

HF_EXECUTE_ACTION

We are providing a SOCM action /XALM/CC4_SX and a ppf processing method /XALM/CC4_SX in parallel. Both actions are nearly doing the same. Above we described how to configure a ppf action using the ppf processing method /XALM/CC4_SX. Alternatively you can call the SOCM action /XALM/CC4_SX by using ppf processing method HF_EXECUTE_ACTION if you want.

EXT_SYS_GUID & ACTION & EXECUTION_MODE

If defining a ppf action you can add some parameters to you action:

• Please optionally add parameter EXT_SYS_GUID with a name of a configuration profile aka External System Guid. In this case you are forcing the use of this profile instead of detecting it automatically. Usually (if this parameters is not there or empty) the profile flagged as default will be used for creation. Usually the profile where a linkage is already established will be used for update. A common use case is the use of multiple external tools (e.g. Service Now and Jira or multiple Jira instances - one for first level support and another for third level support) in one transaction type. In this case you want to use the synchronizing ppf actions for the defined external tool only.

• Please optionally add parameter ACTION with the values C, R, U, L, A, T or any combinations if you want to trigger a certain action. Usually (if this parameter is not there or empty) the action (C)reate or (Update) + (L)ink sync + (A)ttachment sync + Status (T)ransition + (R)ead are executed sequentially. A common use case of this parameter is to define a pull action with value “R” triggering a (R)ead operation only. Another use case is defining a push action with value “CULAT” triggering all outbound send actions without triggering a (R)ead back action.

• Please optionally add parameter EXECUTION_MODE with value 0, 1, 2, 3 or S, C, U, A. This parameter is supported since CC4 ABAP version 2.3.0 (2023/11):

  • 0 or S: This is the standard mode (used if this parameter is not existing or empty) executing the synchronization action synchronously. Usually the ppf action is getting called on transaction save. It is sending a request to the external tool and waiting for a response from the external tool. Contra: This could have negative impact on the performance on save. pro: But on the other hand, you are getting an instant feedback.

  • 1 or C: The synchronization action will be called synchronously on commit work after all changes are done but before save to database will be performed. Pro: You can synchronize all changes even these changes are done between save and commit work. Contra: The transaction cannot be changed by the synchronization action. Therefore no transaction message, no text log, no cross connector log are written. Please use this option only if needed and if suggested by a CC4 expert.

  • 2 or U: The synchronization action will be called synchronously in a own update task after all changes are written to database. Pro: You can synchronize all changes even these changes are done during commit work. Contra: The transaction cannot be changed by the synchronization action. Therefore no transaction message, no text log, no cross connector log are written. Please use this option only if needed and if suggested by a CC4 expert.

  • 3 or A: The synchronization action will be called asynchronously in a parallel task as soon as the transaction is getting unlocked. Pro: You can synchronize all changes even these changes are done between save and commit work or during commit work. The save process will be speeded up because you don’t have to wait till the data exchange with the external tool is getting performed. Contra: The feedback will be saved in the transaction but the end-user might see it only after a refresh. As mandatory prerequisite for this option, the transaction save must switch to display mode to allow the parallel process performing some changes after the synchronization with the external tool. Please perform the configuration steps as described in SAP note https://me.sap.com/notes/1435064. Additional hint: If the external tool is performing a synchronization to SAP Solution Manager and if SAP Solution Manager wants to perform a synchronization back to the external tool, the synchronization will automatically be executed using this mode. There is no need to explicitely specifying execution mode “A”.

AGS_WORK_CUSTOM

If you are using the ITSM scenario and if you are defining and scheduling a manual ppf action you may notice that the ppf action defined by you is not shown in Web UI. This may be caused by a missing configuration in table AGS_WORK_CUSTOM which has to be done once. This configuration should be part of our delivery Transport already.

Message live time

If activated by you during configuration of the configuration profile, some status messages will be shown on execution of the SOCM or PPF actions performing a synchronization call. It can be a success or error message. This message will stay there till a next synchronization call will be triggered. This feature will help you always telling the processor the current synchronization status.

However maybe you like this feature of displaying a message but you don’t like this feature of keeping this message alive till the next sync call is getting executed. To clean up the messages, you have to configure a dummy SOCM condition telling the SOCM framework that our CC4 messages are SOCM check condition messages which have to be removed on start of a new check cycle. If ChaRM is not used, you have to ensure that a PPF action with processing method HF_CHECK_STATUS or HF_SET_STATUS is defined and scheduled on every save or manually.