Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 37 Next »

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.

 Technical details

Following entries can be defined by global settings:

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

 Technical details

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

 Technical details

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

 Technical details

Following field 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

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

 Technical details

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.

 Technical details

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.

 

project.property[devSystems].content ~ "{SYSID}_{MANDT}"

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.

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.

Restriction:

The used SAP attribute(s) used must be created as a prerequisite – attributes names are configured in the Work item > Fields of ITSM system (see also ITSM system configuration). If the SAP attribute does not exist, the process stops and the TR is not created.

The ITSM ID attribute name is configured globally in Global activation settings.

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.

Must be activated in TM if either CREATION or AFTER_WF_A are activated.

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.

Restriction:

The SAP attribute is mapped to a TM attribute having the same name. Attributes names are configured in the Work item > Fields of ITSM system (see also ITSM system configuration). The ITSM ID attribute name is configured globally in Global activation settings.

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.

On this page

  • No labels