Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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
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)
Restriction: It MUST always be defined and active.
Service Now SYS_ID is the unique identifier for all work items in Service Now.
NOTE It is recommend to store also the Unique identifier in a TM attribute. The number of the Work Item may not uniquely identify it in Service Now. (but even if it does not have an TM attribute assigned, it must still be defined).
IS_UI_ID
UI ID
Defines a field as Ticket ID (external value displayed in Service Now, which identifies a Work Item).
Restriction: It MUST always be defined and active.
Service Now NUMBER is the displayed value for all work items in Service Now
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).
Restrictions:
SYS_ID must always have position 0. NUMBER must always have position 1. All active fields must have a position number assigned (>1).
Dev Systems
Each ITSM system must have the development systems configured.
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.
If a development system is enabled for more ITSM systems in “DEV Systems”, the default ITSM displayed in the popup is the one for which the dev system is set as default.
If the dev system is set as default for more ITSM systems, the user has to make a choice in the popup.
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.
Following fields can be defined:
Technical name
Field name
Value
SERV_ID
Server ID
ITSM system ID for which the action is being configured
ITEM_TYPE
Item type
Work Item Type/ Web call resource name (defined in the configuration tables for an ITSM system)
Ex. For integration with Jira there are 2 web calls resources that need to be defined:
GET > For Issues Search
UPD > For Issue Update
ACTION
Action
Possible action values:
For assigning a Ticket ID to a Transport Request:
CREATION (before creation of TR)
AFTER_WF_A (before release of TR, but after the TM popup for Project/Destination) – not fully supported with version 1.
For Updating the ITSM Ticket ID after an action in SAP:
· LINK_EXT (after creation of TR)
· RELEASE (after release of TR):
· Activates 2 steps: After export of TR & After TR insertion into TM Workflow
· APPROVAL (after make approval/ revoke approval in the TM workflow monitor)
· IMPORT (after TR import into target system)
(all other values available in search help are not implemented in this version)
LEVEL_NAME
LEVEL_NAME
The level name has to be filled only for action 'APPROVAL'.
Wild card (*) is allowed.
(not supported for Jira TM IF version 1)
PJ_NAME
PJ_NAME
The project name has to be filled in case of following Actions:
· ‘AFTER_WF_A’
· ‘APPROVAL’
Wild card (*) is allowed.
DESTI_NAME
DESTI_NAME
The destination name has to be filled in case of following Actions:
· ‘AFTER_WF_A’
· ‘APPROVAL’
Wild card (*) is allowed.
APPROVAL_TYPE
APPROVAL_TYPE
This field must be filled only for action 'APPROVAL'
Possible values:
· 't': technical approval
· 'c': content approval
INACTIVE
INACTIVE
‘X’ - Disable action.
ASSIGN_MODE
ASSIGN_MODE
Possible values:
· 'A': Assign Optional’ -> set for CREATION/AFTER_WORKFLOW_ASSIGNMENT
· ‘M’: ‘Assign Mandatory’ -> set for CREATION/ AFTER-WORKFLOW_ASSIGNMENT
· 'R': Reassign -> set for APPROVAL (if user should be able to change ticket assignment at approval time) -> Not supported with TM IF 4 Jira Version 1.
· ‘D’: Display -> if the user wants to perform the check on Ticket number, blocking the operation in case of failure, without the possibility to reassign.
FILTER_QUERY
FILTER_QUERY
For Jira, any valid JQL can be inserted here.
There are 3 placeholders that can be used:
{SYSID} -> will be replaced at runtime with the DEV SID
{MANDT} -> will be replaced at runtime with DEV MANDT
{EMAIL} -> will be replaced at runtime with the email address read from the master data of the calling SAP user.
Ex.
project in projectsForProperty( devSystems, "~", {SYSID}_{MANDT} )
is the part of the filter query used for Jira on Premise to filter the Projects based on the corresponding Project Settings in Jira Plugin.
is the part of the filter query used for Jira on Cloud to filter the Projects based on the corresponding Project Settings in Jira Plugin
assignee = {EMAIL}
is the part of the filter query mapping the SAP user to the Jira user, on the premise both have configured the same email address.
TM User Exits and BAdIs
With Service Pack 2 Hotfix 5, all UserExits have been included in the TM Integration Standard and are automatically called when needed. An explicit configuration is no longer necessary. (No further manual steps are needed from here on)
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:
Go to transaction code SE19
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.
