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 16 Next »

2.

1. 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

TM Workflow step configuration

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

Global activation settings

General settings for activating the TM Integration Framework.

 Technical details

Following entries can be defined by global settings:

Technical name

Field name

Value

Optional

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 SAP Transport Request attributes must exist on the Development systems (TCode SE03).

TITLE1

Title for pop up

Customized texts for the popup title

X

POPUP_TEXT

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

X

TR_TYPE

 

'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.

X

MOD_GET

Name of the function module for getting data

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

X

MOD_SCREEN

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.

X

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.

 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.

2. 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)

3. TM User Exits supported for Jira Plugin

The following TM user exits can be activated, depending on the required integration scenario.

On this page

  1. TM IF Configuration cockpit

  2. Activate BADIs on the Development systems

  3. TM User Exits supported for Jira Plugin

    • Assign Ticket ID

      • BADI_CHECK_BEFORE_CREATION -> Action CREATION

    • Update Ticket ID

      • BADI /RTC/TM_IF_BD_CREATE_REQUEST -> Action LINK_TO_EXT

      • BADI /RTC/TM_IF_BD_DELETE_REQUEST -> Action DELETE_TR

      • BADI_FEEDBACK_AFTER_EXPORT-> Action RELEASE

      • AFTER_ADD2_WF -> No action (Must be activated in TM if either CREATION/AFTER_WF_A are activated)

      • ACTION_LOG -> Action APPROVAL

      • AFTER_IMPORT -> Action IMPORT

  • No labels