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
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 |
---|---|---|
| Transaction header fields | Short Title (up to 40 characters) |
| Activity header fields | Priority |
| Service header Fields | Long Title (up to 120 character) |
| Service Request header fields | Urgency, Impact |
| Sales header fields | External Reference |
| Customer Fields | Any custom field |
| Plain Text Types | Description (long) |
| HTML/Rich Text Types |
|
| Dates, Timestamps, Durations | Duedate Created On |
| Partner Functions | Creator |
| Attachments | URLs and File attachments |
| Categories | Category 1-4 |
| Subject/Refobj | Configuration Item |
| Status | Status |
| Release/Project, Focused Build ITPPM, Focused Build IT Requirement | Landscape |
| Document Flow | Predecessor |
| CC4 Integration Record | External System 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:
Read internal value from business transaction.
Convert value using conversion routine specified in field mapping.
Convert value using value mapping (Int to Ext).
Convert value using conversion routine specified in attribute definition.
Use fallback value defined in attribute definition if value converted so far is initial/empty and if fallback value is not empty.
Send external value to external tool as attribute of a payload, http parameters or as part of the URI.
Inbound / Ext 2 Int:
Receive external value from external tool as attribute of a payload, http parameters or as part of the URI.
Use fallback value defined in attribute definition if value received is initial/empty and if fallback value is not empty.
Convert value using conversion routine specified in attribute definition.
Convert value using value mapping (Ext to Int).
Convert value using conversion routine specified in field mapping.
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)
Object name from table above.
Field name to specify entry we are searching (we want the partner with the BP number entered in SolMan).
Key field from which is read/in which is written. “SMCD0002” describes in this context the field “Tester” seen in SolMan.
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.