Transaction Field Mapping & Conversion

The field mapping has to be provided for every transaction type each. If an attribute is not listed in the mapping for a transaction type, the attribute will not be send/received for processes of this transaction type.

Mappings in the “empty” transaction type apply for all transaction types.

Open

External System

You can find the documentation on the External System level.

Transaction Type

You can find the documentation on the Transaction Type level.

Attribute Name

You can find the documentation on the Attribute Definition level.

Object Name

Object of a business transaction.

Use

A business transaction is made up of several objects. Objects contain data that can be addressed, read and changed using field names and logical keys.

The following objects are currently supported:

Dependencies

Not all objects are supported by all transaction types. In most cases, in addition to the object name, field names and logical keys are also required in order to be able to read or change specific information. Sometimes the field names or logical keys can be omitted and the default values ​​are then used. Sometimes value mapping or value conversion are also required.

Example

Please take a look at the delivered customizing. Please use the value help (F4 help).

Field Name

Field name of the object of a business transaction.

Use

A business transaction is made up of several objects. Each object consists of several fields or has several data. The field name is used to identify exactly one field or piece of information.

In principle, all fields of the supported objects are supported. In some cases, however, only one specific field makes sense. In these cases, the field name can also be left blank and the relevant field will automatically be determined.

The following standard field names are used:

• APPOINTMENT: TIMESTAMP_FROM

• PARTNER: PARTNER_NO

• TEXT: LINES

• TEXT_GEN: TEXT_CONTENT

• ATTACHMENTS: full structure

• DOC_FLOW: EXT_REC_ID

• SUBJECT: CAT_ID

• STATUS: STATUS

Dependencies

The field name must match the object.

Logical Key

Logical key of the object of a business transaction.

Use

A business transaction is made up of several objects. Each object can appear once, but sometimes several times. If an object for a business transaction exists multiple times, the logical key is used to identify exactly one of several objects of the same type.

The following logical keys are currently supported:

• TEXT: Text type or list of text types separated by +. Optionally followed by sorting options ASC or DESC and header options HEAD1, HEAD2, HEAD3 or LOG, separated by space. Options should only be used for logging text types.

• TEXT_GEN: Same as for TEXT.

• APPOINTMENT: Appointment type or appointment duration

• PARTNER: Partner function. Optionally followed by filter options MAIN or ADDITIONAL or ALL, separated by space. Options should only be used for partner functions allowing more than one partners to be assigned.

• SUBJECT: Catalogue Category (If empty, D is used as default to access the first MLC. Use C to access the second MLC.)

• ATTACHMENTS: "URL", "FILE" semicolon-separated list of file extensions including wildcards (*, +), semicolon separated list of filenames including wildcards (*, +), regular expression describing a file extension or regular expression describing a file name.

• DOC_FLOW: empty value (= current transaction), TEMPLATE, PREDOC, SUCDOCS, RELATING, RELATED, ALL. Expert values: VONA link kind (A,B,C,D,E,F,H,I,J): Typically "A" is used for a real predecessor relationship and "E" is used for template usage. Or: pattern <reltype>_<role>_<kind>_<process_type> to address any relationship and direction. <reltype> can be "VONA" for instances. <role> can be A or B. <kind> can be A or E for instances. <process_type> can be any process type. ABAP string patterns * (any string) or + (any single character) can be used. Each component can be empty which will be considered as "*".Alternatively, to character _ as separator, you can use a space.

• ORDERADM_H / CC4_INTEGRATION_RECORD: Here we are supporting a subset of the DOC_FLOW logical key.

  • Empty key for addressing the current/own business transaction.

  • PREDOC, if a predecessor transaction is to be linked when creating the current transaction.

  • TEMPLATE, if a template should be used when creating the current transaction.

  • VONA kind if neither A (PREDOC) nor E (TEMPLATE) should be used on creation.

  • Expert mode: <reltype>_<role>_<kind>_<process_type> with <reltype> = VONA, <role> = A, <kind> not empty and <process_type> any value or empty. Alternatively, to character _ as separator, you can use a space.

  • When reading, only PREDOC for the predecessor and the empty key for the current transaction are supported. TEMPLATE is not supported because the template relationship is getting lost after transaction creation.

Dependencies

The logical key must match the object name and the transaction type configuration.

Logical Key: Texts

Use

A business transaction can have one or more long texts. To one logging text type none, one or multiple long texts can be assigned at the same time. A text cannot be changed only a new text can be added. For a none-logging text type only one text can be assigned at the same time. A text can be changed at any time replacing the previous version.

The cross connector can read and write all text types of a business transaction. Multiple texts per text type are supported. Additional sorting and header options are available since 05/2025.

Details

For each text type used to synchronize text information, you have to choose a text type which is valid for the process type being used.

If the text type is a none-logging text type, you are done, no additional option is needed. This applies to the text log itself which is supported too.

For logging text types you can/should specify the sorting. ASC with sort ascending and DESC will sort descending. SAP is usually sorting descending showing the latest log entry first (have a look at text log). Cross Connector is usually sorting ascending showing the latest log entry last.

After specifying the sorting, you have to specify the header line. LOG or HEAD3 are generating three lines with the text type title/name, the user + timestamp and a separator line. HEAD2 is removing the separator line. HEAD1 is removing the text type title/name additionally.

The text type, the sorting option and the header option have to be separated by space.

Jira

Jira is also supporting multiple long texts. Jira is also supporting logging texts. On Jira side you have to use json paths “/fields/description” for a changeable none-logging text. Or “/update/comment[index]/add/body” (or “/update/comment[0]/add/body”) for a logging text. Jira can add only one comment per update call. Comments on creation are not supported by Jira yet.

For custom-specific texts you have to determine the custom field id you are using and you have to find our whether it is a single text field or a multi text field. The jpath can be similar to /fields/customfield_10049 or /fields/customfield_10049[index] resp. /fields/customfield_10049[0].

Jira Service Management is considering external and internal notes. Please have a look at Long Texts, Descriptions and Comments for details.

As expert you can manipulate the text sent to Jira using the value pattern feature of the attribute definition. Here you can add some fixed texts before and after. Additionally you can concatenate multiple texts/attributes. Since we are sending the text to the Jira API using rest v2 api you can also add some formatting option in the style supported by Jira. (e.g. _cursive_ *bold*, …).

Attribute names

Please use predefined attribute names IVDESCRIPTION (for description), IVSOLUTION (for solution or similar) and IVASSUMPTION (for comment or similar). Additionally you can use attributes IVTEXT01 to IVTEXT10.

If you want to transfer more than 13 texts, you can use any other predefined attribute like IVCUSTOM01 to IVCUSTOM10, IVPARTNER01 to IVPARTNER10 or IVAPPOINTMENT01 to IVAPPOINTMENT10 additionally.

For Solman Inbound you have to use one of the predefined attributes. Because of the fixed structure of our odata service you cannot add and use additional attribute names. Same for Solman Outbound using the Jira DC API provided by our Cross connector app. For Solman Outbound using ServiceNow or Jira standard API you can define and use any attribute name since the payload is generated dynamically.

Logical Key: Partners

Use

A business transaction can have one or more partner functions. To one partner function none, one or multiple partner can be assigned at the same time. If there are multiple partners assigned to one partner function, one of them is flagged as main partner.

The cross connector can read and write all partner functions of a business transaction. Multiple partners per partner function are supported since 05/2025.

Details

For each partner attribute used to synchronize partner information, you have to choose a partner function which is valid for the process type being used.

If there can be maximum one partner to be assigned to this partner function, no additional option is needed.

If multiple partners can be assigned, you have to add an additional filter option telling the cross connector whether you want to address only the MAIN partner or only the ADDITIONAL partners or ALL (main and additional) partners. Please add this option to the partner function separated by a space.

Jira

Jira is also supporting multiple partner types. Jira is also supporting multiple partners per partner type. However Jira is not mixing up main and additional partners, Jira is using two partner fields (e.g. assignee and assignees). On Jira side you have to use json paths /fields/assignee/accountId, /fields/reporter/accountId for a single standard partner. Or /fields/assignees[index]/accountId for a multi standard partner.

For custom-specific partners you have to determine the custom field id you are using and you have to find our whether it is a single partner field or a multi partner field. The jpath can be similar to /fields/customfield_10049/accountId or /fields/customfield_10049[index]/accountId.

For Jira DC you have to replace “accountId” by “name”, if you are using the jpath expressions used to send a payload to Jira standard API. Usually Cross Connector for Jira DC is providing an own API without any jpath expressions currently not supporting multiple partners. if you want to use multiple partners in Jira DC you have to either bypass the odata service provided by our Jira DC app or you have to raise a development request to add the support of multiple partners.

Attribute names

Please use predefined attribute names IVOWNERUSER (for assignee) and IVBPEXUSER (for reporter, business process expert). Additionally you can use attributes IVPARTNER01 to IVPARTNER10.

If you want to transfer more than 12 partner sets, you can use any other predefined attribute like IVCUSTOM01 to IVCUSTOM10, IVTEXT01 to IVTEXT10 or IVAPPOINTMENT01 to IVAPPOINTMENT10 additionally.

For Solman Inbound you have to use one of the predefined attributes. Because of the fixed structure of our odata service you cannot add and use additional attribute names. Same for Solman Outbound using the Jira DC API provided by our Cross connector app. For Solman Outbound using ServiceNow or Jira standard API you can define and use any attribute name since the payload is generated dynamically.

Logical Key: Attachments

Logical key of an attachment.

Use

A business transaction can have one or more attachments. It can be an URL or a file.

The cross connector can read and write all attachments of a business transaction. The logical key is helping to find the right scope. It is used to filter on file extension or filename.

Details

Following values are supported:

• <empty> → All file and URL attachments

• “URL” → URL attachments only

• “FILE” → File attachments only

• “PDF;TXT” → list of file extensions: any PDF or TXT documents (Example)

• “*.PDF” → filename pattern: any PDF document (Example)

• “CA-File_*.pdf” → Attachment generated & attached by Cross Archiver

As an expert you are allowed to use additional logical key values which are not completely mentioned here. Just in short:

You can enumerate filenames or file extensions separated by semicolon. Additionally, you can use the patterns * for any string or + for any character (exact one character). There are examples mentioned above.

Alternatively, you can use regular expressions starting with ^. There is no example mentioned above.

Logical Key: Document Flow

Logical key of a document flow.

Use

The document flow is used to link business transactions to each other. A document flow relation consist of a type and a direction. Additionally, the predecessor / successor relation consist of a kind controlling which data should be copied during creation, after creation and whether the relationship should be kept after creation.

The cross connector can read and write the document flow of a business transaction. The logical key is helping to find the right scope. It is used to filter on relation type, direction, predecessor/successor kind and process type.

Details

Following values are supported:

• <emtpy> → Current Business Transaction

• “TEMPLATE” → Template Transaction

• “PREDOC” → Predecessor Transaction

• “SUCDOCS” → Successor Transactions

• “RELATING” → Relating Transactions

• “RELATED” → Related Transactions

• “ALL” → All Transactions

As an expert you are allowed to use additional logical key values which are not completely mentioned here. Just in short:

You can specify a predecessor/successor kind (data type CRMT_VONA_KIND). Cross connector will use it during transaction creation. You can herewith force a kind different from A (PREDOC) and E (TEMPLATE).

You can specify any relationship, direction, kind and process type using the pattern <reltype>_<role>_<kind>_<process_type>. Knowing this you are able to filter any standard or custom relationship. Wildcards (* for any string and + for any single character) are supported. A component can be left empty which will be considered like "*". To find the correct values, you can use report CRM_ORDER_READ analyzing a business transaction where the requested document flow relation is being used.

Conversion

Conversion routine for the purpose of dynamically converting values from external to internal or internal to external representation.

Use

In most cases the external tool is working with data in a different format than used by SAP. Therefore, a conversion is needed during sending or receiving.

If a customer specific or discrete value mapping is needed, you have to use the value mapping feature.

If an automatic resp. general value conversion is needed, you have to use a conversion routine.

Dependencies

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 value converted so far 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 value received 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

This product is already delivering a lot of conversion routines which can be used out of the box. Additionally, you can implement your own conversion routines by implementing BADI /XALM/CONV.

Filter

Filter option for texts and attachments.

Use

A filter option FULL, LAST or DELTA can be specified. This information is used during reading to determine which texts or attachments should be transmitted. The behavior depends on how the text type is defined, i.e. whether it goes into the text log and can no longer be changed or whether it can be changed at any time.

Changeable texts:

• FULL: Text should always be transferred completely.

• LAST: Same behavior as FULL.

• DELTA: Text should only be transferred if it has been changed since it was last sent.

Logging texts:

• FULL: Text should always be transferred completely. Multiple entries are concatenated.

• LAST: Text should only be transferred if it has been added in the current session.

• DELTA: Text should only be transferred if it has been added since it was last sent.

Attachments:

• FULL: All attachments should always be transferred.

• LAST: Same behavior as DELTA.

• DELTA: Attachments should only be transferred if they were created/attached since the last send.

LAST and DELTA behave the same if a synchronization is carried out every time the business transaction is saved. They behave differently if synchronization only takes place at selected events (e.g. status changes).

Dependencies

The filter option is supported for texts and attachments only.

Example

The default option is LAST. If you leave this field blank, it will be considered like LAST.

Prerequisites:

This field ist existing since CC4 ABAP 2.4.0 (05/2024). Before, the filter option was specified as fieldname or conversion routine.

Disable / Inactive

You can find the documentation on the External System level.

Example Mapping

Example Mapping IVOWNERUSER (Partner fields)

Open

Standard mapping for IVOWNERUSER for transaction “normal change”

1. Object name from table above.

2. Field name to specify entry we are searching (we want the partner with the BP number entered in SolMan).

3. Key field from which is read/in which is written. “SMCD0002” describes in this context the field “Tester” seen in SolMan. Here no additional filter option is used since the assignee (Jira), message processor (Solman ITSM), developer (Solman ChaRM) is usually exact one person.

4. A conversion method applied on the incoming/outgoing values to save in SAP system. In this case, if we retrieve a BP from the SAP system, this BP is converted to the corresponding email address of the user and vice versa.

Example Mapping IVDUEDATE (Appointment fields)

Open

standard mapping for IVDUEDATE

The key SRV_RREADY addresses the “duedate” field visible in SolMan.

The conversion routine used in this example convertes the sap date(time) format in a suitable format for the external tool and vice versa.

Example Mapping IVCUSTOM01 (Custom fields)

Open

Example mapping custom field