External System / Configuration Profile

This is the “head” of your profile with the name (external_system_guid) and other technical settings:

Example configuration profile

External System Id / Configuration Profile

Identify the external system or integration scenarios.

Use
This name is identifying the external tool, the integration scenario and as consequence a set of configuration settings.

Dependencies
Names starting with # or TEMPLATE are reserved and should therefore not be created by customers.

Example
Our recommendation: <Company><Tool><Scenario/Project>

Example: CROSSALM_JIRA_ITSM

Text

A description describing the scenario resp. use case. This description has no functional impact.

Default

Default Profile.

Use
You can flag one or multiple configuration profiles as default. The flagged profile will be selected automatically by the sending action if no configuration profile is explicitly mentioned there.

It is allowed to flag multiple configuration profiles in parallel if and only if they are working on different process types. Please ensure that for one process type there is exact one default configuration profile existing.

Dependencies
If you cannot guarantee the mentioned prerequisite or if you want to integration multiple external tools with one process type, you cannot use the concept of default profiles. You have to mention the used profile in the sending action explicitly.

Please note that the default profile concept is being used only for actions sending a ticket creation to the external tool. For instances, the concept is not being used if the external tool is triggering a ticket creation in SAP Solution Manager. In this case the external tool is telling us the name of the configuration profile already. In the event of changes/updates, the profile to be used is already known and does not need to be determined again.

Example
Please flag one (or multiple or none) profile as default (commonly used) profile.

Usually a customer is defining/using exact one custom specific profile which should be flagged as default profile.

RFC-Destination

FC Destination maintained in SM59 targeting to an external system.

Cross Reference

Enter your own RFC-Destination created previously: CC4 - Set Up - SAP | Create RFC destination to external tool

Use
Create a RFC destination of type "HTTP Connection to External Server" in SM59.

Specify host and port of the external system.

Specify username and password of your technical user used to create or update external tickets.

Use https instead of http.

Register the external certificate in your certificate store in transaction STRUST and select the used certificate store in the RFC destination being used/created here.

Dependencies
Usually, the RFC destination is pointing to host and port of your external system. The complete URI will be generated dynamically based on the RFC destination and the URI specified in the action definition.

If you want to increase security, you can move the left fixed part of the URI to the path prefix of the RFC destination. In this case you will need individual RFC destinations for each single action. You have to maintain the RFC destination at the action level instead of the configuration profile level. You have to short/adjust the URI of each action because you moved some pieces to the RFC destination.

Example
It is recommended to specify only host, port, user and password in the RFC destination and to use one and the same RFC destination for all actions of one and the same integration scenario.

Example: JIRA

Reference Type

Specify the way of dealing with reference profiles.

Ref. Types:

  • Merge: This mode uses the nested entries in reference profiles, unless redefined or inactivated in current customizing profile. All entries in reference profile are valid entries for the current profile, even if not listed in current profile.

  • Lookup: Customizing details are "looked up" in reference profile if a dummy entry (only key value) exists. Thus, all entries to be used from the reference profile can be listed without details in profile and not listed entries are not “looked up”.

  • Complete: The current profile is independent from the reference profile. A possible reference profile can be used to update the current profile.

Use

Cross ALM is delivering multiple reference/template/default profiles. Customers want to create multiple custom specific configuration profiles either for different external tools or different scenarios using one and the same external tool. Most of the configuration settings are the same. Therefore, an inheritance mechanism is helpful to reduce work for creation and maintenance.

One of the following options can be chosen:

  • " " Add Legacy Customizing. / If this option is chosen, the Legacy Customizing configured in profile #1LEGACY will be added, even if the field "Reference Profile" is empty. A customizing setting of the Legacy Customizing profile will only be added if it is not re-defined or inactivated in the current configuration profile. The Legacy Customizing is needed to ensure that a configuration profile is containing the minimum (legacy) configuration settings needed to make the Cross Connector work. This option is existing for legacy reasons only. It shall not be used for new configuration profiles.

  • "M" Merge with Reference Profile. / This mode is adding all customizing settings of the reference profile, unless they are redefined or inactivated in the current customizing profile. All settings of the reference profile will automatically become valid settings of the current configuration profile, even if not listed in current configuration profile. If a configuration is getting modified in or added to the reference profile, this change will apply to the current configuration profile automatically.

  • “L” Look up from reference profile. / Customizing details are “looked up” in the reference profile. All entries from the reference profile to be looked up must be explicitly activated/registered in the current configuration profile. Entries that are not activated/registered are not “looked up”. Activation means that the setting is added to the current configuration profile without the inactive flag being set and without providing any further details. The reference customizing is ignored if the customizing setting is inactivated or redefined in the current configuration profile.

  • "C" Complete (Do not use any Reference Profile). / The current profile is independent from the reference profile. A reference profile can be used to update the current profile on request. Use this option if you want to keep the control on the configuration profile. No reference customizing will be used except #0SYSTEM. The field "Reference Profile" will be ignored. Please be aware of the fact, that you might have to adjust your customizing during upgrade of this product since there is no automatic customizing adjustment provided.

Dependencies

Customizing corrections delivered with a new product version will apply only for option " ", "M" and "L" but not for option "C".

Customizing extensions (new actions or attributes) delivered with a new product version will apply only for option " ", "M" but not for option "L" or "C". Exception for "L": Enhancements to the system customizing will apply as well. Enhancements to other reference profiles will not.

If you want to create or update a new configuration profile, you can use a helper report which will help you generating all needed / missing customizing settings respecting your preferred reference option.

Above it is mentioned, that for reference option "L" you have either to activate a customizing setting defined in the reference profile or you have to (re-)define it in the current configuration profile. This is true for most cases but not the complete story. In particular cases it is allowed to mix both: An attribute can inherited resp. looked up from the reference profile and at the same time the fallback value can be re-defined in the current configuration profile without enforcing the re-definition of the other customizing fields of the same customizing entry.

Example

Usually, you should set up a hierarchy of configuration profiles to minimize configuration work:

0. System: System customizing settings delivered and maintained by Cross ALM.

1. Legacy: Legacy customizing settings delivered and maintained by Cross ALM. It is inheriting customizing of level 0.

1. Root: Default customizing settings for all supported actions, all default attributes and all SAP standard transaction types delivered and maintained by Cross ALM. It is inheriting customizing of level 0 (system).

2. Tool Template. Default customizing settings for a certain external tool delivered and maintained by Cross ALM. It is inheriting customizing of level 1 (root).

3. Company Template. Default customizing settings for your company for a certain external tool. This profile has to be configured and maintained by you. If should inherit customizing settings from a profile of level 2. If option "C" is used, you have to ensure that all needed customizing settings which were usually be taken from level 2, 1 or 0 are included. It is recommended to inherit from level 2 using option "L".

4. Project specific configuration profile. This is the final configuration profile getting used for external tool integration.

After updating the version of the Cross Connector, you should run the configuration update helper report. It will identify added actions, added attribute definitions or added field mappings. It will enhance you configuration profile on request. You might have to perform some manual adjustments afterwards. For instances you have to copy these new customizing entries from SAP standard process types to your custom specific process types. For instances you have to add the changes to a transport request. If you do not want to benefit from these improvements delivered by the new product version (because you just want to synchronize a fixed set of attributes of your custom specific process types), there is no need to run the helper report.

Reference Profile

Reference profile where your profile can perform “lookup” or “merge” adding missing or completing incomplete data and which the configuration profile update report can use for detecting and taking over changes.

Use

Here you have to specify the configuration profile from where all settings shall be inherited based on the reference type. Even if you use reference type "C", you should select a reference profile from where the configuration profile was originally copied from.

Only if a reference profile is mentioned here, the inheritance mechanism and the configuration profile update report can work. Exception: For reference type " " (Legacy) no reference profile has to be specified because it will always be #1LEGACY. Profile #0SYSTEM will always be merged, it will always be the root somehow.

Dependencies

Please maintain the reference type accordingly.

Example

Usually, your reference profile should be TEMPLATE_JIRA_CLOUD, TEMPLATE_JIRA_SERVER, TEMPLATE_SERVICENOW or similar.

Logging Option

Specify the logging scope.

Use

Please choose one of the following options:

" " / Disabled: Log nothing

You don't want to use any logging feature. This is the default option for legacy reasons.

"A" / Application Log: Log processing details in application log

You want to write internal processing details to the application log which can be analyzed using SLG1 or SLGD. No status or processing details will be visible to the end-user.

"M" / Message: Log synchronization status in trans. message log

Like option "A", but you want to display the synchronization status in the transaction message log additionally.

"T" / Text: Log synchronization status in text log

Like option "M", but you want to write the synchronization status into the text log of the transaction additionally.

"F" Full: Log processing details in text log

Like option "T", but you want to log internal processing details into the text log additionally.

This option should be used for error analysis only.

Dependencies

Logging Option “A” is available since CC4 ABAP 2.3.0. In version prior to this version you have to chose M, T or F for Solman Outbound and you have to configure the parameter /XALM/CC4_ACTIVATE_LOG in AGS_WORK_CUSTOM table for Solman Inbound. From 2.3.0 the parameter /XALM/CC4_ACTIVATE_LOG is not needed anymore but still supported switching to logging option “A”.

Example

It is recommended to choose option "T".

Disabled / Inactive

Disable this configuration setting.

Use

It will be considered like it is not existing. Using this option, you can disable configuration settings without removing it.

Dependencies

If looking up or merging from another reference profile is configured, a disabled configuration setting stays disabled even if it is enabled/active in the reference profile.

Example

Usually all settings shall be active (= not inactive).