REST API Configuration (REST API for Solution Manager)

General REST API configuration

In the general REST API configuration, values can be assigned to predefined keys. The following keys are currently available.

Assignment of External IDs

In this view you can define per transaction type or for a transaction type pattern in which way external IDs for ChaRM objects should be stored. In addition, a checkbox can be used to define whether multiple external IDs can be assigned to a ChaRM object.

If you define multiple rules, for example, a rule for the specific business transaction type ZMMJ and a generic rule Z*, a search for a specific assignment is performed first, and if no specific assignment is found, a search for a generic assignment is performed.

The following scenarios are provided for storage for External IDs:

• External IDs are stored in a custom field

• External IDs are stored in a standard field

• External IDs are stored in the "/GAL/SM_CHARM_EX" table of the addon (default)

The first two options are only available if the assignment of an External ID and a ChaRM object is one-to-one.

Storage of External IDs in a custom field

To store external IDs in a custom field, the option "Is custom field" must be checked in the maintenance view and the technical name of the custom field must be entered in the "Existing field name" field. You can view the technical names of custom fields using the CRMD_CUSTOMER_H table.

Storage of external IDs in standard fields

The definition for standard fields is a bit more complicated and is only possible if the field in the GenIL Model Browser is directly related (1:1) to the access object "BTAdminH". You can see if the requirement is met in transaction GENIL_MODEL_BROWSER.

To activate the storage in a standard field, the option "Is existing field" must be marked. In addition, the technical field name must be entered in the "Existing field name" field, the name of the relationship to the access object "BTAdminH" must be entered in the "Relationship name" field, and the technical name of the associated physical table must be entered in the "Table name" field. The "Object type" field must also be filled with the object type of the object to which the standard field belongs. A list of allowed object types can be found in the table CRMC_OBJECTS.

Example: You want to store a unique External ID in the standard field PO_NUMBER_SOLD. Using transaction GENIL_MODEL_BROWSER you can find out that the name of the relationship is BTHeaderSalesSet. From table CRMC_OBJECTS you deduce that the object type of the object "SALES" is assigned the value "11" and the table name is generally composed of CRMD_<OBJECT_NAME>, where <OBJECT_NAME> corresponds to the name of the object from CRMC_OBJECTS. In this example, the table name is therefore CRMD_SALES.

The header data of a CRM object (table CRMD_ORDERADM_H) is linked to the subobjects via the table CRMD_LINK. The column GUID_HI corresponds to the GUID from table CRMD_ORDERADM_H and GUID_SET corresponds to the GUID from the table, which is derived from the object type OBJTYPE_SET via table CRMC_OBJECTS.

Webhook definitions

The following three maintenance views are available in transaction /GAL/SM_REST_CONFIG for defining a webhook:

• Webhook definition for the maintenance of the endpoint and general settings of the webhook.

• Webhook filter to define specific filter criteria for different webhooks

• Webhook authentication, if the endpoint of a webhook requires authentication

General webhook definition

The following settings are available under the general webhook settings.

Webhook filter criteria definition

In the Webhook filter criteria maintenance view, you can either define a pattern for External IDs or filter on specific values in the addon table "/GAL/SM_CHARM_EX".

Two fields are available in the maintenance view for defining a pattern for External IDs:

• Ext. ID filter: pattern for external IDs where the asterisk character (in character "*") is used as wildcard

• Ext. ID filter option: selection of an operator to be used for comparing an External ID with the filter. The selection is made using a list of values that supports the following options: <, <=, =, >=, >, Contains pattern, Does not contain pattern.

Filtering on External ID can be useful if the External ID contains a constant value that delimits an organizational unit, a project, or something similar. For example, Jira task IDs contain a prefix that corresponds to the associated Jira project.

The table "/GAL/SM_CHARM_EX" contains 8 columns (CUSTOM_FIELD1 - CUSTOM_FIELD8) where customer specific content for a ChaRM object can be stored. In case ChaRM objects can be linked with external objects from different source systems, an abbreviation of the source system can be stored in one of the available columns, e.g. SNOW, ADO or JIRA. In the filter criteria, it can then be defined that a webhook is only triggered if the ChaRM object is assigned to a specific abbreviation, e.g. SNOW.

The following fields are available in the maintenance view for defining a customer-specific filter:

• Custom Filter ID: selection of the customer specific fields from table "/GAL/SM_CHARM_EX" in which the filter value is stored.

• Custom Filter value: The customer's own filter value.

• Custom Filter option: selection of an operator to be used for the comparison of the filter value.