Value Mapping

Perform a static value mapping from internal value to external value or external value to internal value in case a dynamic conversion is not existing or not supported.

An attribute without a value mapping might sill be correct. The value mapping might be inherited from the reference profile or a conversion routine might be used or there is no value mapping needed at all.

You can deactivate or delete not used value mappings. Deletion is allowed here exceptionally.

Details on inheritance/deactivation can be found in Create/Update/Copy/Configure Template

Not all attributes/field mappings require a value mapping:

empty value mapping

A value mapping is only needed, if the representation of a specific, static, not changable values differs between SAP system and external system and if a conversion routine cannot bridge this gap.

“Attribute” defines for which attribute this mapping is valid.

“Internal Value” represents the value used in SAP Solution Manager.

“External Value” represents the matching “translation” in the External System.

 

Basic value mapping examples:

internal value

external value

effect

internal value

external value

effect

*

 

Every not explictly mapped value will be send as initial to External System.

 

*

Every not explicitly mapped value will be received as initial from External System.

A

1

Value “A” read in SAP System will be mapped and send as “1” to External System. Value “1” received from External System will be mapped and stored as “A” .

B

 

Value “B” read in SAP system will be mapped and send as empty to external system. Empty value received from External System will be mapped and stored as “B” in SAP System.

 

2

Value “2” received from External System will be mapped and stored as empty value. Empty value read from SAP System will be mapped and send as “2” to External System.

 

 

Keep empty value empty.

A empty value might mean either “ignore it and keep value unchanged” or “clear/delete it”. If a attribute is ignored and not cleared but you want to perform a clear/delete, you have to use the control value #DELETE#. You can use it either here in the value mapping or alternatively as fallback value in the attribute definition.

The behaviour differs for Jira Cloud, Jira DC and ServiceNow. It differs between inbound and outbound direction. (Ignore: Inbound + Jira Cloud Outbound + ServiceNow Outbound, Delete: Jira DC Outbound but maybe different behaviour for different attribute types [partner, text, dates, simple fields])

Internal Value

Internal value read from or written to a Business Transaction in SAP Solution Manager.

Use

You can specify a value mapping from an internal value to an external value (Solman Outbound) or value mapping from an external value to an internal value (Solman Inbound).

The internal value could be an exact matching value like a business partner number, a user status number, a priority number or any other internal value of a business transaction. Please use report CRM_ORDER_READ to read internal data/values of a business transaction.

The internal value could be an operation value alternatively. Following operation values are supported:

Outbound / Int 2 Ext:

  • * (asterisk) --> Each internal value which is not explicitly specified in the value mapping table should be mapped to a specific external value. (helpful for mapping of partners)

  • (whitespace) --> The empty value should be mapped to a specific external value.

Inbound / Ext to Int:

  • #IGNORE# --> The field should be ignored. It should not be changed in business transaction.

  • #DELETE# --> The field should be cleared/deleted/removed. It should be changed in business transaction.

  • (whitespace) --> Same as #IGNORE# or #DELETE#. A whitespace will behave like #DELETE# if a non-initial external value was received or set as fallback value. It will behave like #IGNORE# otherwise (if no external value got received or set).

Partial matching values (regular expressions or using of *, ?, +, % in between or at the beginning/end) are not supported yet.

Dependencies

Please note that additionally a conversion routine can be used to perform a dynamic value mapping resp. conversion. Also a fallback value could be specified somewhere. In general, the value conversion is getting performed in following sequence. Therefore, the conversion result could be a mixture of multiple conversion rules.

Outbound / Int 2 Ext:

  1. Read internal value from business transaction.

  2. Convert value using conversion routine specified in field mapping.

  3. Convert value using value mapping (Int to Ext).

  4. Convert value using conversion routine specified in attribute definition.

  5. Use fallback value defined in attribute definition if converted value is initial/empty and if fallback value is not empty.

  6. Send external value to external tool as attribute of a payload, http parameters or as part of the URI.

Inbound / Ext 2 Int:

  1. Receive external value from external tool as attribute of a payload, http parameters or as part of the URI.

  2. Use fallback value defined in attribute definition if received value is initial/empty and if fallback value is not empty.

  3. Convert value using conversion routine specified in attribute definition.

  4. Convert value using value mapping (Ext to Int).

  5. Convert value using conversion routine specified in field mapping.

  6. Write internal value to business transaction or remove/delete a value from business transaction.

Example

Mapping of business partners:

  • Chose conversion routine BP_MAIL or BP_NO in field mapping.

  • Map business partner e-mail address or business partner number to a Jira User Id.

  • Specify a value mapping from "*" (asterisk) to "" (whitespace) and "" (whitespace) to "*" (asterisk) as fallback for both directions. This will map unknown partners to empty.

Prerequisites

Operations #IGNORE# and #DELETE# are supported since CC4 ABAP version 2.3.0.

External Value

External value received from or send to an external tool.

Use

You can specify a value mapping from an internal value to an external value (Solman Outbound) or value mapping from an external value to an internal value (Solman Inbound).

The external value could be an exact matching value like a assignee user id, transition id, a priority name or any other external value of a external ticket. Please perform a GET call in your web browser to read all values of a certain external ticket.

The external value could be an operation value alternatively. Following operation values are supported:

Inbound / Ext 2 Int:

  • * (asterisk) --> Each external value which is not explicitly specified in the value mapping table should be mapped to a specific internal value. (helpful for mapping of partners)

  • (whitespace) --> The empty value should be mapped to a specific internal value.

Outbound / Int to Ext:

  • #IGNORE# --> The field should be ignored. It should not be changed in external ticket.

  • #DELETE# --> The field should be cleared/deleted/removed. It should be changed in external ticket.

  • (whitespace) --> Same as #IGNORE# or #DELETE#. A whitespace will behave like #DELETE# if a non-initial internal value was read. It will behave like #IGNORE# otherwise (if no internal value got read).

Partial matching values (regular expressions or using of *, ?, +, % in between or at the beginning/end) are not supported yet.

Dependencies

Please note that additionally a conversion routine can be used to perform a dynamic value mapping resp. conversion. Also a fallback value could be specified somewhere. In general, the value conversion is getting performed in following sequence. Therefore, the conversion result could be a mixture of multiple conversion rules.

Outbound / Int 2 Ext:

  1. Read internal value from business transaction.

  2. Convert value using conversion routine specified in field mapping.

  3. Convert value using value mapping (Int to Ext).

  4. Convert value using conversion routine specified in attribute definition.

  5. Use fallback value defined in attribute definition if converted value is initial/empty and if fallback value is not empty.

  6. Send external value to external tool as attribute of a payload, http parameters or as part of the URI.

Inbound / Ext 2 Int:

  1. Receive external value from external tool as attribute of a payload, http parameters or as part of the URI.

  2. Use fallback value defined in attribute definition if received value is initial/empty and if fallback value is not empty.

  3. Convert value using conversion routine specified in attribute definition.

  4. Convert value using value mapping (Ext to Int).

  5. Convert value using conversion routine specified in field mapping.

  6. Write internal value to business transaction or remove/delete a value from business transaction.

Example

Mapping of business partners:

  • Chose conversion routine BP_MAIL or BP_NO in field mapping.

  • Map Jira User Id to business partner e-mail address or business partner number.

  • Specify a value mapping from "*" (asterisk) to "" (whitespace) and "" (whitespace) to "*" (asterisk) as fallback for both directions. This will map unknown partners to empty.

Prerequisites

Operations #IGNORE# and #DELETE# are supported since CC4 ABAP version 2.3.0.

Example: Process type

example value mapping used for Jira: “normal change” ↔︎ “Task”

Make sure, what kind of “ticket type” is sent form your external tool. Is it the name of the ticket type or maybe an id for the ticket type?

Example: Status

IVSTATUS: This attribute is reflecting the current status of a ticket. On side of SAP Solution Manager the status is the letter “E” and a four digit number. You can find the valid status codes in table TJ30.

On Jira side the current status is a number. You can find the number in the workflow definition.

 

Only for Jira IVTRANSITION: This attribute is reflecting a transition from one status to another status. On side of SAP Solution Manager a transition can be a PPF action performing a status change or it can be a status as mentioned above. On Jira side the transition has an id. You can find the number in the workflow definition.

If Jira is calling SAP Solution Manager it is telling us the Jira status of a ticket/issue using attribute IVSTATUS. If SAP Solution Manager is reading details of a Jira ticket, we are receiving the Jira status of a ticket/issue using attribute IVSTATUS. But if SAP Solution Manager wants to perform a status change on Jira side, we have to trigger a transition using attribute IVTRANSITION. You don’t need to care when which attribute is being used but you have to maintain a proper value mapping for both attributes.

Since this mapping is dependent on a certain transaction type, you have to maintain this mapping in the section of the related transaction/process type.

Example: Partners

This mapping is required for all attributes, that send BP/names of user. Standard User attributes are IVOWNERUSER and IVBPEXUSER.

Depending on your external tool and possible configurations make sure what kind of id (a user id, system id or even an email address) is sent to SolMan.

Example: Priorities

Most likely the represenntation of proritiy values in SolMan will be different from the values used in your external tool.

The used attributes regarding priorities are: IVPRIORITY, IVIMPACT and IVURGENCY. The priority is represented as natural number between 1 and 4 in SolMan and impact and urgency as 2-digit number.

You can check the priority ids of your external system in the tool’s documentation.