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.

Entries without any details are correct. The details will be inherited from the reference profile.

Please never delete entries. Deactivate them if not needed.

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

image-20240507-141006.png

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:

Object Name

Description

Examples

Object Name

Description

Examples

ORDERADM_H

Transaction header fields

Short Title (up to 40 characters)
Value Points
Effort Points

ACTIVITY_H

Activity header fields

Priority

SERVICE_H

Service header Fields

Long Title (up to 120 character)

SRV_REQ_H

Service Request header fields

Urgency, Impact

SALES

Sales header fields

External Reference

CUSTOMER_H

Customer Fields

Any custom field

TEXTS

Plain Text Types

Description (long)

TEXT_GEN

HTML/Rich Text Types

 

APPOINTMENT

Dates, Timestamps, Durations

Duedate

Created On

PARTNER

Partner Functions

Creator
Assignee

ATTACHMENTS

Attachments

URLs and File attachments

SUBJECT

Categories

Category 1-4

SERVICE_OS

Subject/Refobj

Configuration Item

STATUS

Status

Status
Status Description

ITPPM

Release/Project, Focused Build ITPPM, Focused Build IT Requirement

Landscape
Project
Wave
Sprint

DOCFLOW

Document Flow

Predecessor
Template

CC4_INTEGRATION_RECORD

CC4 Integration Record

External System Guid
External Id
External Guid

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

  • 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:

  • TEXTS: Text type

  • TEXT_GEN: Text type

  • APPOINTMENT: Appointment type or appointment duration

  • PARTNER: Partner function

  • ATTACHMENTS: "URL", "FILE" or semicolon-separated list of file extensions

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

  • DOC_FLOW: 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.

  • ORDERADM_H:

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

    • 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 the current transaction got created.

  • CC4_INTEGRATION_RECORD:

    • Empty key for addressing the current/own transaction.

    • PREDOC, if the predecessor transaction should be addressed instead of the current transaction.

Dependencies

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

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 IVOWNERUSER (Partner fields)

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.

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

This example is valid for attributes IVBPEXUSER, IVPARTNER01..IVPARTNER10 as well.

Example Mapping IVDUEDATE (Appointment fields)

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.

This example is valid for attributes IVAPPOINTMENT01..IVAPPOINTMENT10 as well.

Example Mapping IVCUSTOM01 (Custom fields)