SAP TM Integration Framework

Owned by Maria Hald
Last updated: Nov 29, 2022
12 min read

TM IF Configuration cockpit

The configuration cockpit, transaction /RTC/TM_IF_CONFIG, needs to be run on the TM Server only.
A default configuration is provided for activating a JIRA ITSM system, under following names:

  • TEMPLATE_ JIRA CLOUD

  • TEMPLATE_ JIRA SERVER

Calling transaction /RTC/TM_IF_CONFIG

Global activation settings

General settings for activating the TM Integration Framework.

Following entries can be defined by global settings:

Technical name

Optional

Field name

Value

Technical name

Optional

Field name

Value

SWITCH_OFF

 

'X' = TM Integration framework is inactive

Switch off the Integration Framework.
(‘X’ -> switched off)

ITSM_ATTR

 

Name of TR attribute for storing the ITSM server id

Name of the SAP Transport Request Attribute  
The attribute ZRTC_TM_ITSM_ID is delivered as default.

The SAP Transport Request attributes must exist on the Development systems (TCode SE03).

TITLE1

X

Title for pop up

Customized texts for the popup title

POPUP_TEXT

X

Name of Long Text (SO10) to be displayed in the popup

Name of a Smartform Text Module to be additionally displayed on the popup, as information

TR_TYPE

 

X

'A' = All, ' ' = Customizing and Workbench

Possible values:

  • 'A' : All type of transport requests;

  • ' ': Customizing and Workbench.

 This setting applies only to APPROVAL event. Define it as ‘A’ if Transport of Copies should also have a Ticket ID assigned.

If the entry is not defined, ‘ ‘ is considered as default value.

MOD_GET

X

Name of the function module for getting data

Name of customer function module to fetch the Ticket information from the ITSM System

MOD_SCREEN

X

Function module which contains the (individual) screen.

Feature not implemented in this version.

Name of the individual customer function module, which calls an individual screen.

 

ITSM systems configurations

In this step, you’ll configure parameters for external server.

  • ITSM system

     

Following fields can be defined:

Technical name

Field name

Value

Mandatory

SERV_ID

Server ID

Unique identifier for ITSM system.

 

ACTIVE

Active

‘X’ – ITSM is actively used by the Integration Framework

 

SERV_DESC

Server Description

Description of ITSM system (used in the popup_to_assign)

 

SERV_PATH

Server Path

Path of the external server (used in RFC destination).

 

SERV_RFC

RFC Destination

Name of the RFC destination of type G (HTTP Connection to External Server)

X

ITSM_TYPE

ITSM Type

Supported ITSM types:

  • JIRA (both On Premise and On Cloud)

  • SNOW (Service Now)

  • POLARION

X

 

  • Work Item

     

Following fields can be defined:

Technical name

Field name

Value

SERV_ID

Server ID

Unique identifier for ITSM system.

ITEM_TYPE

Item type

Identifier for Work Item Type for ITSM system (Ex. Incidents, Change Requests…)

Or for Web Call Resource name (ex. Search for Issues, Update Issue)

ITEM_DESC

Item description

Description of Work Item Type/ Web call resource

ITEM_PATH

Item path

Technical table path of the Work Items/web call resource name

*SUB_ITEM_PATH

Sub-item path

Technical URL used in order to get fieldnames and descriptions via Web Service call for the Work Item from Service Now ‘sys_dictionary’ table

Ex. ‘/api/now/table/sys_dictionary?sysparm_query=name=task&sysparm_fields=column_label,element’

*SNOW specific field.

ACTIVE

Active

Defines a Work Item type as Active (the one used for the integration for the Assign Ticket ID actions)

Only one Work Item Type must be active.
Otherwise, the interface will pick up the first active item type. 

 

  • Work item > Fields

Following field can be defined:

Technical name

Field name

Value

Technical name

Field name

Value

SERV_ID

Server ID

Unique identifier for ITSM system.

ITEM_TYPE

Item type

Identifier for Work Item Type for ITSM system

FIELD_NAME

Field Name

Technical name of the field used internally

Technical restriction:

  • Can contain only ‘A’-‘Z’, ‘0’-‘9’,’_’,’-‘

  • Max length 30 char

FIELD_DESC

Field Description

Field label/description used for UI – F4 popup_to_assign

FIELD_PATH

Field Path

Path of the value in the response JSON format of the web call

Used separator: ‘/’

FIELD_ALIAS

Field Alias

Object name used in the web call for restricting the result of the web call to the relevant information 

 Jira: The “FIELDS” param (which can be specified multiple times) gives a comma-separated list of fields to include in the response. This can be used to retrieve a subset of fields.

 

ACTIVE

Active

Active flag

IS_UNIQUE

Uniquie

Defines a field as unique identifier of the Work item type (internal generated value in Service Now)

IS_UI_ID

UI ID

Defines a field as Ticket ID (external value displayed in Service Now, which identifies a Work Item). 

ATTR_NAME

Attribute

TM/SAP attribute name for storing the value of the field assigned to a TR.

POS

Position

Position for display of the field in the selection POPUP (POPUP for assigning a Work Item to a Transport Request).

 

  • Dev Systems

 

  • Optional settings

     

Following fields can be defined:

Technical name

Field name

Value

SERV_ID

Server ID

Unique identifier for ITSM system.

R3_SID   

Def SID   

Default development system
This parameter is used when displaying the popup to assign a Ticket ID.

TR_TEXT

Short text

Option to change the Transport Request description when assigning a Ticket id.

The value can be set using placeholders: {<FIELDNAME>}, where FIELDNAME is the technical FIELD_NAME set in “Fields” step of the configuration.

OVERWRITE_TEXT

Overwrite

‘X’ – Overwrite the TR description

‘’ – Append the defined Short text to the TR description

 

Settings for TM Workflow Step

In this step the configuration table defines the behaviour for each action.

An action can be defined for a specific Transport level, Project and/or Destination.

For an easy configuration, these entries can be copied changing the Server ID and setting the proper RFC destination.

 

TM User Exits and BAdIs


Next steps are only relevant if you use lower Service Pack 2 Hotfix 5.
The following is a list of TM UserExits and BAdIs that had to be done before Service Pack 2 Hotfix 5.

Activate BADIs on the Development systems

Following BADIs must be activated on the development system(s):

  • /RTC/TM_IF_BIM_CREATE_REQUEST – After TR creation event (SE01/SE10) - Update ITSM system with TR number

  • /RTC/TM_IF_BIM_DELETE_REQUEST – After TR deletion event (SE01/SE10) – Update ITSM system deleting the TR number

Steps:

  1. Go to transaction code SE19

     

  2. Mark checkbox ‘Implementation is active’ under ‘Runtime behavior’ (1)  and Activate the object (2)

 


TM User Exits supported for Jira Plugin

Depending on the required integration scenarion TM user exits or BAdIs are to be activated.

How to activate a TM User Exit

  • Call transaction /RTC/TM on the TM Server

  • Goto “TransportManager -> Systems & Groups

  • Switch to edit mode and place the cursor on that system you want to activate the exit implementation for.
    That system is described with “Location for activation”

  • In context menu, select “Maintain user exits …”

  • In the next screen switch to edit mode

  • Navigate to the required user exit definition and place the cursor on that type

  • Press the “Assign function module” button

  • Provide the name of function module and save

How to activate a BAdI

  • Call transaction SE19

  • Enter BAdI and press CHANGE

  • Mark checkbox ‘Implementation is active’ under ‘Runtime behavior’

  • Activate the BAdI

Scenario: Assign Ticket ID

TM User Exit: BADI_CHECK_BEFORE_CREATION

This TM User Exit is used e.g. to force developers to supply mandatory information for a transport request while it is created.

Type

TM User Exit

Location for activation

Development system

TM User Exit

BADI_CHECK_BEFORE_CREATION

Function module

/RTC/TM_IF_UE_CREATION

Action
within the TM integration framework

CREATION

The implementation for the TM Integration Framework checks if the ACTION CREATION has been activated in Settings for TM Worflow step, and depending on the configuration, prompts the user to select an Ticket ID to be assigned.

A GET web service call is made at this point to retrieve all items/issues that meet the filter criteria defined for this action or just to check the work item entered manually by the user.

If no work item is selected, the TR cannot be created (for assign mode – M “Assign Mandatory”). For “Assign Optional” (A), the TR can be created and the Ticket ID can be assigned later.

The selected Ticket ID and other values, if configured so, are saved in corresponding SAP TR attributes. Additionally, an SAP attribute is assigned to the TR for storing the ITSM ID corresponding to the selected Ticket Id.

 

Scenario: Update ITSM (Jira issue)

BAdI: /RTC/TM_IF_BD_CREATE_REQUEST

This badi implementation is called after a request has been created.

Type

BAdI

Location for BAdI activation

Development system

BAdI Implementation

/RTC/TM_IF_BIM_CREATE_REQUEST

Action
within the TM integration framework

LINK_TO_EXT

The implementation for the TM Integration Framework checks if the Action LINK_TO_EXT has been activated in Settings for TM Worflow step.

If a Ticket ID has been assigned to the TR, it performs an update of the assigned Jira issue, passing the details of the created Transport Request.

 

BAdI: /RTC/TM_IF_BD_DELETE_REQUEST

This badi implementation is called after a request has been deleted from SAP (SE01/SE10).

Type

BAdI

Location for BAdI activation

Development system

BAdI Implementation

/RTC/TM_IF_BIM_DELETE_REQUEST

Action
within the TM integration framework

DELETE_TR

The implementation for the TM Integration Framework checks if the DELETE_TR has been activated in Settings for TM Worflow step.

If a Ticket ID has been assigned to the TR, it performs an update of the assigned Jira issue, deleting the reference to the Transport Request from the issue.

 

TM User Exit: BADI_FEEDBACK_AFTER_EXPORT

This user exit is called every time after a request has been exported.

Type

TM User Exit

Location for activation

Development system

TM User Exit

BADI_FEEDBACK_AFTER_EXPORT

Function module

/RTC/TM_IF_UE_AFTER_EXPORT

Action
within the TM integration framework

RELEASE

The implementation for the TM Integration Framework checks if the Transport Request was assigned an External Work Item/Ticket during the Creation process.

If this is the case, the External Work Item/Ticket has been stored into an SAP transport request attribute assigned to the TR.

If the corresponding ‘RELEASE’ action has been configured in table /RTC/TM_IF_STAT the update of the corresponding Jira issue is performed.

 

TM User Exit: AFTER_ADD2_WF

This user exit is called every time after a request has been added to the Transport Manager Workflow.

Type

TM User Exit

Location for activation

TM Server

TM User Exit

AFTER_ADD2_WF

Function module

/RTC/TM_IF_UE_AFTER_ADD2WF

Action
within the TM integration framework

No action is assigned to this user exit.

The user exit must be activated in TM if either CREATION or AFTER_WF_A are active.

The implementation for the TM Integration Framework checks is the Transport Request was assigned an External Work Item/Ticket during the Creation or Release process.

If this is the case, the External Work Item/Ticket has been stored into an SAP transport request attribute assigned to the TR.

The value is therefore moved and stored in the corresponding TM attribute. If the TM attribute has not yet been defined in TM, it will be automatically created.

Also, if the corresponding ‘RELEASE’ action has been configured, and the SAP attributes have been successfully copied to the TM attributes, the update of the corresponding Jira issue is performed.

 

TM User Exit: ACTION_LOG

This user exit is called at every time when an entry is tracked in the requests action log. So, it can be used to start any additional tasks that should be executed after specific process steps in Transport Manager.

For the TM integration, the ACTION_LOG user exit is currently used for executing an update of the assigned Ticket ID after granting or revoking an approval.

Type

TM User Exit

Location for activation

TM Server

TM User Exit

ACTION_LOG

Function module

/RTC/TM_IF_UE_ACTION_LOG

Action
within the TM integration framework

APPROVAL

The implementation for the TM Integration Framework checks if the Transport Request just approved has a Ticket ID assigned.

Depending on the configuration, if the Action APPROVAL is active for the Update Work Item, the Jira issue is updated with the latest information from SAP about the TM workflow details.

 

TM User Exit: AFTER_IMPORT

This user exit is called after the import of a complete import queue.

Type

TM User Exit

Location for activation

Target System of the import

TM User Exit

AFTER_IMPORT

Function module

/RTC/TM_IF_UE_AFTER_IMPORT

Action
within the TM integration framework

IMPORT

The implementation for the TM Integration Framework checks if the Transport Request just imported has a Ticket ID assigned.

Depending on the configuration, if the Action IMPORT is active for the Update Work Item, the Jira issue is updated with the import return information.