SAP Community - Cloud Integration

Create DataType and Message Type artifact in Cloud Integration capability of SAP Integration Suite

2024-07-10T10:43:24.414000+02:00

Introduction

SAP Cloud Integration version 6.54.xx comes with new feature, where in one can create Datatype and Messagetype as reusable design time artifacts in Cloud Integration capability of SAP Integration Suite

This feature is available only in SAP Integration Suite standard and above service plans.

SAP Cloud Integration version 6.54.xx software update is planned on mid of July 2024 (date and time subjected to change).

Create DataType :

1. Open the Integration Suite Tenant and navigate to Design -->Integrations and API's

2. Create an Integration Package or open an existing one.

3. Navigate to the Artifacts tab and click on Edit in the top right corner

4. Click on Add drop down and select Data Type from the list

5. Add Data Type dialog is displayed with Create (radio button) selected by default.

6. Enter the values for the fields Name, ID,Target Namespace, Description ,select the category - Simple Type(selected by default) or Complex Type for the Datatype you want to create and click on Add or Add and Open in Editor

7. On Click of Add, the Data Type artifact with the provided name gets created and is listed in the Artifacts list page

8. On Click of Add and Open in Editor, the Data Type artifact gets created with the provided name and the artifact gets opened in the Editor in display mode.

9. The Editor contains three tabs : Overview,Structure and XSD.The Structure is shown by default when the artifact is opened. It displays the structure of the datatype in a tree table with the following columns :

Name : Contains the Name of the node(element or attribute).For Root node the name is same as the name of the Datatype and it cannot be edited.
Category : This column shows whether the root element has subnodes or not . For root node it is either Simple type or Complex Type and for submodes it can be either Element or Attribute. You cannot change values in this column.
Type: This column displays the type with which the node is defined.Here you select a built-in data type or reference to an existing data type for an element or attribute. You must specify a type for attributes.
Occurrence: Determines how often elements occur.For attributes, you can determine whether the attribute is optional or required.
Restrictions : This column displays the facets (if any) defined incase the node is defined by a built-in primitive type or a user defined Simple type Datatype

9. Switch to edit mode and to define/build the Structure of the Datatype. On selecting the first row(rootnode),the Add drop down in the table header gets enabled (for category complex type) and also the details of the row are displayed in the right side section of the editor.

10. Simple Type Data Type :

No child nodes can be added
Root node is defined by string built-in primitive datatype.
Click on the root node and the Properties sheet which contains the details of the node selected is displayed on the right side of the editor. In Edit mode ,user can edit the Type ,define the restrictions applicable for the Type selected.

11.Complex Type Data Type :

To add child nodes:

Click on the root node and the Add drop down in the table header gets enabled.

Add -->Element to add child element node

Add -->Attribute to add attribute node

Add -->Rows to add multiple Elements/Attributes

Click on the newly added node and define the details in the Properties sheet

12. Once the Structure is defined,Click on Save to save the artifact as Draft, Save as Version to save the artifact as versioned artifact.

13. XSD tab displays the read only view of the xsd schema of the Datatype artifact

Create MessageType:

1. Open the Integration Suite Tenant and navigate to Design -->Integrations and API's

2. Create an Integration Package or open an existing one.

3. Navigate to the Artifacts tab and click on Edit in the top right corner

4. Click on Add drop down and select Message Type from the list

5. Add Message Type dialog is opened

6.Enter the values for the fields Name, ID, XMLNamespace, Datatype to be Used, Description, and click on Add or Add and Open in Editor

7. On Click of Add, Message Type artifact gets created and is listed in the Artifacts list page

8.On Click of Add and Open in Editor, MessageType artifact gets created and the artifact gets opened in the DataType Editor with Structure tab loaded by default in non-edit mode . The rootnode Name would be same as the Message Type name ,Category as Element and Type as Data Type Used (if selected in the Add Message Type dialog)

9. Overview tab in Edit mode is as shown below :

10 XSD tab :

11. Datatype Used to create a Message type can be changed in Overview tab or in Structure tab. Switch to edit mode and select the root node in the Structure tab.The properties sheet gets displayed on the right side of the page with Datatype Used field as editable.

12. No other nodes(child nodes) are editable in the Message Type artifact.

Latest Pipeline Concept enhancements: Custom error handling and others

2024-07-11T10:14:27.850000+02:00

We have lately shipped a new version of the Pipeline Concept package on the SAP Business Accelerator Hub based on customer and partner feedback, this is now version 1.0.5. The package can be accessed from here. If you have already copied the package to your workspace in your SAP Integration Suite tenant, you can simply run the update of the package to be able to use the latest features.

As part of the package, we have now added a change list which allows you to see all increments that we have shipped so far. In the latest version, we have delivered the following:

Extension for custom error handling
In generic IDoc inbound processing flow, display list of IDoc numbers in case of IDoc bulk messages
For IDoc inbound, sender interface is calculated as a combination of MESTYP, IDOCTYP and CIMTYP
Supporting test mode via testMode header in the allowed headers configuration
In standard error handling, copied messages from the dead letter queue are switched to DEBUG log level

The custom error handling extension is a sort of customer exit which allows you to implement your own error handling in a separate integration flow which is then called via ProcessDirect instead of the standard error handling if the standard error handling doesn't meet your requirements. This way you can customize the pipeline processing without changing the generic integration flows that we ship as part of the pipeline concept. For more details, see Monitoring and Error Handling in the Pipeline Concept.

For improved monitoring of IDoc bulk messages, all IDoc numbers are stored in a custom header property. This allows you to search the message processing logs in the message monitoring based on a particular IDoc number. Furthermore we have revised the sender interface for IDoc messages. Before it contained the message type only, now it's a combination of the message type, the IDoc type and a potential IDoc extension which brings you more flexibility in setting up your IDoc scenarios. See Special Cases.

If you like to run your integration scenarios using a regression test tool, you may benefit from the test mode flag. This is simply a header which is passed through the whole sequence of pipelines. Depending of your test case setup you may then pass the test message to a virtualized or mocked receiver instead of to the actual receiver. By the way, our partners providing regression test tools already support the pipeline concept in their tools. See Testing the Pipeline.

We are currently working on the next increment. For the test flag for instance we plan to extend the generic flows so that test messages which go into an error won't be restarted. Furthermore, we plan to extend the partner directory approach that is used to dynamically configure the runtime behavior. In some cases, the partner ID which is limited to 60 chars might not be sufficient, so we need to react on this. Furthermore, we like to provide you the option to use alternative partners which provides you more flexibility in setting up your integration scenarios, e.g., with this, sender wildcard scenarios can be easily setup.

So, stay tuned. And if you have further ideas, requirements, feedback feel free to reach out to me or simply leave a comment.

NetSuite Adapter for SAP Integration Suite

2024-07-12T15:37:03.059000+02:00

SAP announced the NetSuite adapter for Integration Suite this month. For those customers using NetSuite ERP, the NetSuite adapter for SAP Integration Suite is the ideal solution to enable fast and robust integrations of NetSuite in your business processes.

You can now seamlessly integrate data from diverse sources into the NetSuite ERP platform and elevate your organization’s efficiency by reducing efforts to create a listed set of integration workflows with the NetSuite adapter.

What is NetSuite?

NetSuite is an ERP system; with multi-suite features, it's an extensive business management platform designed to handle critical functions like sales, marketing, finance, accounting, inventory management, procurement, and more.

NetSuite’s centralized data accessibility ensures seamless operations across different functions and locations. It provides invaluable operational insights, reporting, and analytics, enhancing financial visibility and decision-making.

What is the NetSuite Adapter?

With the NetSuite adapter, you have the capability to establish a connection with the NetSuite application and execute a variety of operations with different features.

Key Features

Support for multiple API versions: NetSuite supports multiple API versions with an editable API version field enabling users to input the latest supported version.
Secure authentication based on Tokens: The NetSuite adapter supports the Token-Based Authentication (TBA) mechanism which increases overall system security. Every call between NetSuite and SAP Cloud Integration is secured by Tokens.
Support for multiple NetSuite operations: The NetSuite adapter supports various operations like Add, Get, Delete, Async Add List, etc.
Dynamic configuration with headers and properties: Assigning dynamic values to different properties allows enhanced flexibility to your integration flows. You can also refer to dynamic parameters using SAP Cloud Integration exchange headers and properties.
Processing more than one record at a time: Some operations can be performed on one or more new instances of a record in NetSuite. As an example, the addlist operation can be used to add one or more new instances of a record to NetSuite.
Processing more than one record of data asynchronously: Some operations can be performed on one or more new instances of a record in NetSuite in an asynchronous manner. In general, for asynchronous operations, bulk records are sent to NetSuite without the need to wait for a response.
XSD Generator: To help speed up the integration, an XSD generator in the form of an Eclipse Plug-in is provided alongside the adapter. With this Eclipse Plug-in/Workbench, it is possible to generate an XSD which includes the structure of an Account Record. The generated XSD can then be imported into Cloud Integration and used for mapping purposes.
Full integration support for Custom Records and Fields: In addition to supporting all the standard NetSuite Records (or entities), the Adapter integrates with all the Custom Objects in NetSuite.

How does the adapter work?

NetSuite Adapter allows you to perform various functions related to finance, accounting, inventory management, etc. Let’s look at a simple operation get an employee in NetSuite using the NetSuite Adapter for SAP Integration Suite.

Get an Employee in NetSuite

Before we begin, it is assumed that employee type records are available in NetSuite for querying. Our example illustrates how the NetSuite Adapter allows querying to get an employee. The process begins with a client initiating an HTTPS request to an endpoint for retrieving employee information from NetSuite.

Connect to NetSuite

Field	Description
Address	Specify the address of NetSuite to be used for the connection. This address typically includes your NetSuite Account ID. NetSuite URLs often follow the pattern: https://<accountid>.suitetalk.api.netsuite.com. Example: https://12345-sb1.suitetalk.api.netsuite.com
Account ID	Specify the Account ID to be used for the connection. To find the account ID in NetSuite, you can usually locate it in the account's URL when logged in. Additionally, it might be available in the NetSuite account settings or administration section. Example: 1112711_SB1
Authentication	Select your Authentication Mechanism. Currently, only the Token-Based Authentication (TBA) is supported.
Consumer Credentials Alias	This field should refer to a security material (of type User Credentials). This User Credential should include both Consumer Key (as username) and Consumer Secret (as password).
Token Credentials Alias	This field should refer to a security material (of type User Credentials). This User Credential should include both Token ID (as username) and Token Secret (as password).
Timeout (in ms)	Specify the maximum waiting time (in milliseconds) while establishing a connection with NetSuite. The default Timeout is 60000 ms.

Prepare Request Body and Mapping

You can use a content modifier to ensure that the request payload includes all the necessary parameters NetSuite requires for querying employee data.

The message body should include the internal ID/external ID of the employee.
Note: For more information about internal ID/external ID, see NetSuite documentation.

Alternatively, you can enable Create Request From Properties and specify the ID type and
ID Value in the fields.

Next, we use a mapping to ensure that the request contains all necessary parameters and is correctly structured for querying employee data. To help speed up the integration, an XSD generator in the form of an Eclipse Plug-in is available alongside the adapter.

Our NetSuite Eclipse Plug-in allows you to generate desired XSD and import it in an Integration Flow and use it in mappings. You can add it before the Request-Reply Step. This way, you can create the correct XML request message to create or modify a resource in NetSuite.

Furthermore, the Eclipse Plug-in XSD Generator helps you generate up-to-date XSDs for your NetSuite resources for all the different operations. Once the message mapping is complete, the transformed request is sent to NetSuite.

Execute Get using the NetSuite Adapter

To retrieve details related to an employee, you need to specify the API version and operation as get. This selection allows you to access the specific record type employee, enabling you to fetch comprehensive information associated with that employee.

The response from NetSuite further undergoes message mapping again to ensure it is transformed into a format that the client system understands and can process. You can also use XSDs generated by the NetSuite Eclipse Plug-in to create a mapping to handle the response message returned by NetSuite.

The client system receives and interprets this response, extracting and utilizing the retrieved employee information as needed.

Quick Links

For detailed information about NetSuite adapter configuration, see NetSuite Adapter Guide.

Note: The NetSuite adapter is available as part of your SAP Integration Suite license.

Avoiding Multiple Destination Creation for Integration Between SAP ERP and SAP Integration Suite

2024-07-12T15:37:23.892000+02:00

When integrating SAP ERP (ECC, S/4 HANA) with SAP Integration Suite, it’s common to create separate destinations for each iFlow. This can lead to an excessive number of destinations, which can be cumbersome to manage. Here are two methods to streamline this process and avoid creating multiple destinations:

Method 1: Certificate-Based Authentication and create_by_url Class

One effective way to reduce the number of destinations is to establish certificate-based authentication between SAP ERP and SAP Integration Suite. This method allows you to securely authenticate and communicate without needing a separate destination for each iFlow.

Setup Certificate-Based Authentication: Ensure that both SAP ERP and SAP Integration Suite trust each other’s certificates.
Use the create_by_url Class: This ABAP class can dynamically create HTTP connections using URLs, thus avoiding the need for predefined destinations.

Sample code :

DATA: lo_http_client TYPE REF TO if_http_client.
cl_http_client=>create_by_url( EXPORTING  url                = 'Pass URL Here'
                                          ssl_id             = 'Pass SSL Id'
                               IMPORTING  client             = lo_http_client
                               EXCEPTIONS argument_not_found = 1
                                          plugin_not_active  = 2
                                          internal_error     = 3
                                          OTHERS             = 4 ).
* Check for exceptions
IF sy-subrc <> 0.

ENDIF.
* Disable logon popup
lo_http_client->propertytype_logon_popup = lo_http_client->co_disabled.

* Set the HTTP method to POST
lo_http_client->request->set_method( 'POST' ).

* Send the HTTP request
lo_http_client->send(
    EXCEPTIONS
        http_communication_failure = 1
        http_invalid_state         = 2
        http_processing_failed     = 3
        http_invalid_timeout       = 4
        OTHERS                     = 5 ).

* Check for exceptions
IF sy-subrc = 0.
    * Receive the HTTP response
    lo_http_client->receive(
        EXCEPTIONS
            http_communication_failure = 1
            http_invalid_state         = 2
            http_processing_failed     = 3
            OTHERS                     = 5 ).
ENDIF.

Method 2: Create RFC Destination with Blank Path Prefix and Use create_by_destination Class

Another approach is to create a general RFC destination in transaction SM59 with only the host specified and leaving the path prefix blank. You can then dynamically set the specific path for each request using the header field ~request_uri.

RFC Destination :
RFC Destination

Sample code :

DATA: lo_http_client TYPE REF TO if_http_client.

* Create HTTP client using the destination name
cl_http_client=>create_by_destination(
    EXPORTING
        destination              = 'DestinationName'
    IMPORTING
        client                   = lo_http_client
    EXCEPTIONS
        argument_not_found       = 1
        destination_not_found    = 2
        destination_no_authority = 3
        plugin_not_active        = 4
        internal_error           = 5
        OTHERS                   = 6 ).

* Check for exceptions
IF sy-subrc <> 0.

ENDIF.

* Disable logon popup
lo_http_client->propertytype_logon_popup = lo_http_client->co_disabled.

* Set the HTTP method to POST
lo_http_client->request->set_method( 'POST' ).

* Set the specific path for the request
lo_http_client->request->set_header_field(
    name  = '~request_uri'
    value = 'PassYourPath' ).

* Send the HTTP request
lo_http_client->send(
    EXCEPTIONS
        http_communication_failure = 1
        http_invalid_state         = 2
        http_processing_failed     = 3
        http_invalid_timeout       = 4
        OTHERS                     = 5 ).

* Check for exceptions
IF sy-subrc = 0.
    * Receive the HTTP response
    lo_http_client->receive(
        EXCEPTIONS
            http_communication_failure = 1
            http_invalid_state         = 2
            http_processing_failed     = 3
            OTHERS                     = 5 ).
ENDIF.

By implementing these methods, you can significantly reduce the number of destinations required for integration between SAP ERP and SAP Integration Suite, making the process more efficient and easier to manage.

Integration of SAP Task Center, Azure and ServiceNow - SSO, User Provisioning and Token exchange

2024-07-19T16:10:57.124000+02:00

During the configuration of Task Connect, an integration between ServiceNow and SAP Task center, we devoted significant effort to addressing security concerns, particularly focusing on user authentication and user provisioning. Given the widespread use of Azure as an identity and token provider, we developed a method to synchronize users and groups across ServiceNow, SAP Task Center, and Azure.

In this document, you will find the scenario overview, related architectural diagrams presenting the different components and how they interact with each other and what are the steps to follow to configure the connection between ServiceNow, SAP Task Center and Azure.

1. Scenario overview

The starting point in this scenario is the user's authentication and access token issued by the SAP Cloud Identity tenant's authentication service (IAS), indicated as AT (IAS) APP in returned by step 2 in figure 1 below and following the notation <token type> (<issuer>) <audience>. The complete token exchange is orchestrated by the OAuth 2.0 and OpenID Connect (OIDC) authorization and authentication frameworks and their respective token types, which are access tokens (AT), refresh tokens (RT), and identity tokens (ID). Thus, AT (IAS) IAS is an access token, issued by the IAS tenant's OAuth 2.0 authorization server, with an audience set to the IAS tenant's client ID. All tokens except for refresh tokens are formatted as JWTs. Compared to the token exchange in the previous parts of this blog series (see part I, Interoperability and standards, for more details), SAML 2.0 - or more precisely the SAML assertion as an OAuth 2.0 authorization grant defined in section 2.1 of RFC 7522 - is no longer used in this scenario. Instead of transforming between different token formats (JWT to SAML and back to JWT), this scenario only uses JWTs for the token exchange. It is important to note that for this token exchange no direct trust relationship between the application on BTP and Azure AD is required. The application only has a trust relationship to the IAS tenant, and the IAS tenant maintains the trust relationship to the Azure AD tenant (and vice versa).

All authentication requests for the business application on BTP (SAP TASK CENTER) are forwarded by the IAS tenant to the Azure AD tenant which is configured as a corporate identity provider (IdP) in IAS. IAS acts as a proxy and delegates authentication to Azure AD in the role of the relying party to the corporate identity provider. The IAS tenant therefore requires an application registration in Azure AD.

Note: For the TaskConnect integration configuration to work, the SAP Task Center should be configured according to the following documentation: https://help.sap.com/docs/task-center/sap-task-center/initial-setup

2. Users authentication and token exchange

The user accesses the BTP business application's SAP Task Center. The app delegates authentication to the IAS tenant using OIDC. It starts the authentication process by redirecting the user' browser to the IAS tenant's OAuth server authorization endpoint at https://<IAS tenant name>.accounts.ondemand.com/oauth2/authorize and sending an OAuth authorization request.
Because the user is not yet authenticated at the IAS tenant, the user's browser is redirected to the IAS tenant's single sign-on (SSO) endpoint at https://<IAS tenant name>.accounts.ondemand.com/saml2/idp/sso.
The business application is configured in IAS to pass all authentication requests to Azure AD as its corporate IdP. Therefore, IAS sends an OAuth authorization request to the Azure AD tenant's OAuth authorization endpoint.
The user gets prompted by Azure AD to enter the credentials. Upon successful authentication, Azure AD sends the authorization code to IAS by redirecting the user's web browser to the URI specified in the previous request.
IAS receives the authorization code and sends an access token request to Azure AD's token. Azure AD issues an access token and refresh token (RT(AAD)IAS which is cached for later use in step for the authenticated user with an audience set to the IAS tenant's OIDC name.
The BTP business application requests a client assertion from the IAS tenant to use it in the subsequent requests for the token exchange via the IAS tenant's OIDC proxy. The client application sends a token request to the IAS tenant's token endpoint. The POST request is authenticated with the client ID and secret of the business application in IAS. The client assertion from IAS takes the form of a signed JWT that proofs the application's identity to AAD when requesting tokens via the IAS corporate IdP OIDC proxy.
The business application exchanges the IAS-issued ID token into an Azure AD-issued access token via the IAS tenant's OIDC proxy token exchange endpoint. The POST request uses the assertion parameter to pass the base64-encoded IAS ID token of the user.
IAS token service sends a refresh token request using RT(AAD)IAS cached in step 5 to obtain a new access token AT(AAD)APP for the business application,
The business application uses the Azure AD On-behalf-Of (ObO) flow for requesting the access token
Finally, the business application calls the ServiceNow to take actions to the signed-in user's tasks.
ServiceNow validate the token using OIDC provider to verify ID tokens configuration with the same application registered in Azure which issues an access token and refresh token in step 5.

3. User provisioning - Azure SAP

Use SAP Cloud Identity Services - Identity Provisioning to provision users from Microsoft Azure Active Directory to SAP Cloud Identity Services - Identity Authentication.

4. User provisioning & SSO - Azure-ServiceNow

Use ServiceNow enterprise application in Azure to provision users from Microsoft Azure Active Directory to ServiceNow instance
Use the same ServiceNow enterprise application created in step 13 in Azure to authenticate users from Microsoft Azure Active Directory to ServiceNow instance

5. Technical service flow

You need to create integration user for SAP Technical connection and choose how SAP Task Center will authenticate when technical connection is used (delta jobs in SAP are using this technical connection)

For example, you can use Basic Auth or OAuth:

For basic auth provide username and password to the team who is configuring the connection to ServiceNow.
The BTP business application requests a client assertion from the IAS tenant to use it in the subsequent requests for the token exchange via the IAS tenant's OIDC proxy.
For OAuth follow these steps in ServiceNow (account with admin role is required)
1. Open System OAuth -> Application Registry. Click New and choose "Create an OAuth API endpoint for external clients". Configure the record and share username, user password, client id and client secret with the team configuring the connection to ServiceNow

6. Register the applications in Azure AD for IAS tenant and SN OIDC provider to verify ID tokens.

The token exchange and OIDC proxy setup between the SN, IAS, and the Azure AD tenant, requires a trust relationship which is established by registering one application in the Azure AD tenant

“SAPIASTenant” represents the SAP Cloud Identity Service tenant.

Step 1
Login to Azure Portal (e.g. with your Microsoft 365 E5 developer subscription’s admin account) and select Azure Active Directory from the portal menu.

Select App registrations from the left-side menu.

Step 2
Click + New registration

Step 3
Enter "<SAP IAS Tenant>" for the Name of the new application registration.

Replace <SAP IAS Tenant> with your friendly name

Select "Web" from the dropdown list in the Redirect UR I section.

Enter your IAS tenant's redirect UR Iin the Redirect URI section's text field:https://<IAStenant name>.accounts.ondemand.com/oauth2/callback.Replace <IAS tenant name> with your tenant's name.

Click Register.

Step 4
Copy the newly generated Application (client) ID to a temporary text file. You will need it in the next step for deploying the sample application.

Step 5
Select Manifest from the navigation menu to edit the application registration's manifest file.
Change the value for the field "accessTokenAcceptedVersion" from null to 2.
Click Save.

7. Configure trust to the IAS tenant in Azure AD

Trust to the IAS tenant is configured in Azure AD with a new federated identity credential. In addition, a client secret is required for the initial token exchange in step 5 of figure 1. Both credentials will be configured for the application registrations in the following step.

Step 6
Select the SAPIASTenant app from the list. (created in step 3)
Select Certificates & secrets from the menu and switch to the Client secrets tab.
Click + New client secret.

Step 7
Enter "<SAPOIDCProxy>" for the Description.
Click Add.

Step 8
Click Copy to clipboard in the Value column and paste it to a temporary text file. You will need it later in the setup process.

Step 9
Create another one secret for ServiceNow
Enter "<ServiceNow>" for the Description.
Click Add.

8. Configure permissions and scopes in Azure AD

To request the Outlook calendar event on behalf of the user, the business application (SAPBTPGraphApp) requires the Graph API permission Calendars.Read. SAPBTPGraphApp also exposes the custom scope "token.exchange".This scope is referred to as a (downstream) API permission for the SAPIASTenant application registration and required for steps 7 and 8 in figure 1. For the initial token request to Azure AD (see step 5 in figure 1 and figure 2), the SAPIASTenant application exposes the custom scope "ias.access".

Step 10
Go to Expose an API in the navigation menu.
Click + Add a scope.

Step 11
Accept the default value for the Application ID URI.
Click Save and continue.

Step 12
Enter "ias.access" for the new Scope name. Provide an Admin consent display name and description.
Click Add scope.

Scope name:
ias.access

Admin consent display name:
IAS Tenant Access

Admin consent description:
Access to SAP Cloud Identity service Application

Step 13
Copy the full-qualified URI of the new scope (api://<client id>/ias.access) from the clipboard to temporary text file. It will be used in a later setup step.

Step 14
Add Optional claim to the token.
Navigate to Token configuration
+ Add optional claim
Token Type - ID
Select "email" and add

Step 15
If message about API permissions required appear
select the checkbox - Turn On Microsoft Graph email permission (required for claim to appear in token)
Click "add"

Step 16
Grant Admin Consent

Step 17
Navigate to authentication
Scroll down to Implicit grant and hybrid flows
Select the tokens you would like to be issued by the authorization endpoint:
Select the checkbox ID tokens
Click Save

9. Configure Azure as an OAUTH OIDC provider on ServiceNow

Step 18
Open the ServiceNow instance
Navigate to All > System OAuth > Application Registry.
Click New, click Configure an OIDC provider to verify ID tokens.

Step 19
Fill the form.

Field	Description
Name	A unique name that identifies the OAuth OIDC entity.
Client ID	The client ID of the application registered in Azure in step 4. The instance uses the client ID when requesting an access token.
Client Secret	The client secret of the application registered in Azure in step 31.
OAuth OIDC Provider Configuration	The OIDC provider (ADFS, Auth0, Azure AD, Google, Okta) can be used to validate the JWT token. Click the record of your OIDC provider configuration to validate the User Claim and User Field are set appropriately. If you check Enable JTI claim verification, the ServiceNow JWT token validation also validates the JTI sent by the provider. See next step for more details
Clock Skew	The number, in seconds, for the constraint to be considered valid. The default is 300.
Comments	Additional information to associate with the application.
Application	The name of the application containing this entity.
Accessible from	Select an option to make it accessible from all application scopes, or this application scope only. (all scope by default)
Enforce Token Restrictions	Select to only allow tokens to be used with APIs set to allow the authentication profile. You can set grant access using an API access policy. For more information, seeCreate REST API access policy. Default: Unselected.
Active	Select the check box to make the OAuth application active.
Redirect URL	The URL of the OAuth application for receiving the authorization code. (automatically added when save the application
End Session Endpoint URL	The URL endpoint which enables after a session ends.(not required
Enable force authentication	Option to enable force authentication for users. (not required)

Step 20
OAuth OIDC Provider Configuration
Click on the search icon and then New

OIDC Provider - A unique name that identifies the OIDC provider

OIDC Metadata URL - the OIDC provider OpenID Connect metadata document (details in next step)

User claim: email
User Field: the field in SN which contain mail value

Enable JTI claim verification: Disable

Step 21
Navigate to azure application which created in step 3 - Overview - Endpoints - OpenID Connect metadata document

Step 22
Navigate to Oauth Entity Scope and add
offline_access,
Open id

Click Update.

Step 23
Navigate to the Oauth Entity Profiles which is automatically created when Save Oauth OIDC entity.

Verify that the Grant type is is Resource Owner Password Credentials and then add the OAuth Entity Scopes created in the above step.

Step 24
Add Auth Scope:
useraccount

Step 25
Navigate to the created in step 34 Oauth OIDC Entity and copy the redirect url

Step 26
Navigate to Azure App registered in step 3
Authentication
Add the url from the previous step. (do not remove or replace the url added in step 3 when create the application)
Save

10. Setup user provisioning - Azure >> SAP

Step 27
Launch a browser window and access your Azure portal using the URL: https://portal.azure.com/.

You will need to authenticate to your Azure AD using your admin credentials.

Step 28
Click Microsoft Entra ID.

Step 29
Click App Registration >> New registration.

Step 30
Specify a name for your app and click Register

Step 31
Click API permission >> Add a permission.

Step 32
Select Microsoft Graph.

Step 33
Click Application permissions.

Step 34
From the list of API permissions, expand User and select User.Read.All.

Step 35
From the API list also select Group >> Read.All and Directory >> Read.All. Click Add permissions at the bottom of the screen once done.

Step 36
The permissions are not granted by default. To grant the permissions, click Grant admin consent for Default Directory.

Step 37
Click Yes on the popup message and confirm that all permissions are granted.

Step 38
Click Overview from the left panel. Make a note of the Application (client) ID. You will need this later when creating the source system in IPS. Click Add a certificate or secret.

Step 39
Click New client secret.

Step 40
Specify a description and expiry time for the client secret.

Step 41
You should have client secret added successfully. Make a note of the value field as you will need it later when creating the source system in IPS.

Step 42
Navigate to the main overview page of Azure AD and make a note of your Primary domain. You will need this value when creating the source system in IPS.

Step 43
Follow the blog https://community.sap.com/t5/technology-blogs-by-sap/provision-users-from-microsoft-azure-ad-to-sap-cloud-identity-services/ba-p/13546054 and specific hint on filtering users by a group in Identiy Provisionning Source system Properties, add aad.group.filter=displayName eq '<group_name>':

11. Establish trust between task sub account and IAS

Step 44
Go to BTP Cockpit->Security->Trust Configuration

Step 45
Select "Establish trust" and choose the IAS

Step 46
Select "Establish trust" and choose the IAS

Note: This creates an OIDC application in IAS for the subaccount

NB: Task Center/Service Now integration works only with OIDC trust between Task Center subaccount and IAS

Step 47
This would create an application in iAS

For more information, you can check: https://help.sap.com/docs/btp/sap-business-technology-platform/establish-trust-and-federation-between-uaa-and-identity-authentication

12. Setup the corporate identity provider and OIDC proxy in SAP Cloud Identity tenant

Step 48
Login as an administrator to your SAP Cloud Identity service administration console at
https://<IAStenant name>.accounts.ondemand.com/admin

Step 49
Go to Identity Providers > Corporate Identity Providers and click Create.
Enter a Display name(e.g. "Azure Active Directory") and click Save.

Step 50
Click on Identity Provider Type from the Trust settings of the new corporate identity provider.

Step 51
Select OpenID Connect Compliant from the list.
Click Save.

Step 52
Click on OpenID Connect Configuration from the Trust settings of the new corporate identity provider. 

Step 53
Enter your Azure AD tenant's OIDC Discovery URL (https://login.microsoftonline.com/<AAD tenant ID>/v2.0) Click Load.

The Issuer field gets populated from the loaded Azure AD tenant's OIDC metadata.

Step 54
Enter the SAPIASTenant's client ID in the Client ID field. In the Client Secret field, enter the value of theOIDCProxysecret copied in step 8.

Click Validate.

Step 55
Verify a successful validation of the OIDC configuration.

Click OK.

Step 56
Click + Add

Step 57
Copy and paste the full-qualified URI of the SAPIASTenant application's custom scope (api://<client id>/ias.access) copied in step 13 for the new scope.

Click Save.

Step 58
Click+ Add again and add the scope:
"email"
"openid"
"offline_access"

Click Save.

Step 59
Click Save.

Step 60
Go to Applications & Resources > Applications
Select the application from "Establish trust between Task subaccount and IAS" step – step 47

Click Attributes

Step 61
Navigate to Attributes and add

Name: "xsuaa-persist-corporate-idp-token"
Source: Expression
Value: true

Save

Step 62
Select "Conditional Authentication"
In the "Default Identity Provider", choose the Azure provider configured in steps 48-59, Click Save

13. Configure destinations for SAP in the BTP sub-account

SAP Task Center uses destinations to connect to Service Now task provider

 Client Specific configuration:

aadTokenEndpoint: Azure AD token endpoint athttps://login.microsoftonline.com/<AAD tenant ID>/oauth2/v2.0/token
iasTokenEndpoint: SAP Cloud Identity service tenant's token endpoint athttps://<IAStenant name>.accounts.ondemand.com/oauth2/token
iasTokenExchange: SAP Cloud Identity service's token exchange service endpoint athttps://<IAStenant name>.accounts.ondemand.com/oauth2/exchange/corporateidp

Step 63
Go back to the SAP BTP Cockpit and navigate to your CF subaccount.
Select Connectivity > Destinations from the navigation menu.
Click New Destination.

Step 64
Enter the following values for the first destination:
Refer to 6. TECHNICAL SERVICE FLOW

Click Save.

Step 65
Repeat steps 63 and 64 with following values for the second destination:

Refer to 10. CONFIGURE AZURE AS AN OAUTH OIDC PROVIDER ON THE SERVICENOW , step 21.

AuthnContextClassRef = urn:oasis:names:tc:SAML:2.0:ac:classes:X509
clientKey = token service password=client secret
Token service user = client id

Task Center documentation for Third Party destination setup: https://help.sap.com/docs/task-center/sap-task-center/connect-third-party-task-provider-and-sap-task-center

Click Save.

14. Test the scenario

Step 66
Use SAP Task Center Administration app to check the status of the configured connector destination, following: https://help.sap.com/docs/task-center/sap-task-center/working-with-task-center-administration-app

Step 67
Use SAP Task Center Web app, to validate that tasks from the new destination are seen by business users (for more information, see: https://help.sap.com/docs/task-center/sap-task-center/sap-task-center-web-app)

Optimized Error Management and Retry Strategy with IBM MQ on SAP Cloud Integration

2024-07-31T23:28:02.587000+02:00

Target Audience:

This blog is primarily aimed at the SAP Integration community looking for a Retry and Reprocessing mechanism for SAP Cloud Integration, where IBM MQ is used as the message broker.

Motivation:

As we transition to cloud-based solutions, data storage costs are on the rise. Utilizing modern iPaaS solutions with data persistence will significantly increase the operational costs for integrations. For SAP Cloud Integration (CI), there is an additional consideration of a tenant-based storage limit of 32 GB.
We employ IBM MQ as the message broker between the third-party application and SAP CI. This message broker provides temporary persistence to handle outages and intermittent message failures, allowing us to retry messages using this persistence. The solution outlined in the blog addresses asynchronous inbound message delivery to SAP via SAP CI.

Solution Approach:

The core flow will transfer failed messages to the Retry Queue, appending ErrorType and Retry count headers to each message.
A second flow (Retry flow) will be scheduled to execute at regular intervals. This flow will connect to the Retry Queue and, depending on the ErrorType and RetryCount headers, will either transfer the message to the Backout Queue or return it to the Main Queue.
Messages designated with ErrorType= MappingError (since Mapping Errors cannot be retried directly) or with RetryCount > n (where n -> maximum number of retries) will be directed to the Backout Queue (Discarded messages). All other messages will be routed to the Main Queue(Reprocess messages) for retry attempts (ErrorType= NonMappingError, a Delivery Error that can be retried) .
To understand this let’s consider 3 messages in the RetryQueue with the below headers the Retry flow will move them as below:

Core Flow

In the above flow, I did not include the mapping step. However, if you have a mapping step, the ErrorType should be set to MappingError before the mapping step, and reinitialized to NonMappingError before delivery. This ensures the correct ErrorType is received in the exception sub-flow.

Retry Flow:

All the failed messages from the Core Flow is sent to the Retry Queue . Based on the ErrorType and RetryCount these messages would have to be reprocessed. We will need to connect to the IBM MQ Queue manager to publish these messages to either the Main Queue (Reprocess messages) or Backout Queue (Discard messages) by picking them from the Retry Queue. For this we will need the below information (these are externalized and initialized as Headers in the flow):

Queue Manager Connection Details
Queue Name (Retry Queue, Backout Queue, Main Queue)
Credential or Certificate for Authenticating the Queue Manager (We have used Certificate based authentication)
In the retry flow Process Retry Messages is a Groovy script step which works as below:

SAP Cloud integration (CI) uses QPID JMS 0.59 for its AMQP Adapter implementation.

I have created a Java Archive (JAR) file based on the same version of QPID JMS Implementation to receive and send messages from and to respective Queues (AMQP Client):
https://github.com/apache/qpid-jms/blob/0.59.0/qpid-jms-examples/src/main/java/org/apache/qpid/jms/example/Receiver.java
The code also contains the logic to check ErrorType and publish messages to the respective Queues i.e.
Messages designated with ErrorType= MappingError or with RetryCount > n (where n -> maximum number of retries) will be directed to the Backout Queue. All other messages will be routed to the Main Queue for retry attempts.
We have used TLS Authentication to authenticate our connection to the Queue Manager in the Java code. Please refer the below blog to set your certificates for authentication in the Java code:
https://www.baeldung.com/java-custom-truststore
This is then called from the Groovy script Process Retry Messages. The script will essentially pass all the externalized details like the Queue and Queue Manager connection details and the authentication details from the Security Artifacts in SAP CI to the function in the Java Archive (JAR).
Please refer the below blog to understand how to fetch security artifacts from SAP CI:

https://community.sap.com/t5/technology-blogs-by-members/sap-cpi-fetch-all-security-artifacts-don-t-read-this/ba-p/13483159

Pros

Since the failed messages are persisted outside SAP CI in IBM MQ. There is no risk of overloading the persistence layer like in the case of alternative 2.
The development effort is less as the developer would only have to create the core flow and send the failed messages with the right headers. The Retry flow would only need few configurations to set it up for a specific integration. (The Retry Flow will only be built once and reused for the remaining integrations)
Messages experiencing prolonged connectivity issues or data-related issues are transferred to the Backout queue, where they can be analyzed later.

Cons

The configuration requires three queues (Main, Retry, and a Backout Queue), departing from the conventional IBM MQ setup of just a Main and Backout Queue.
The script responsible for retrying failed messages may require support from respective teams in case of performance issues.
Not suitable where we would need retries for very small intervals' (less than a minute).

Request everyone to provide any improvements, suggestions or concern wrt. to the strategy outlined in the blog.

Sending Form-Data from SAP Integration Suite: Best Practices and Techniques

2024-08-01T11:20:20.448000+02:00

Disclaimer

Multipart/form-data is a complex content type used to send HTML forms with binary (non-ASCII) data via HTTP POST, as specified in RFC-2045. Finding a standard method for this in SAP Integration Suite can be challenging, but there’s a workaround.

In this article, we explore practical solutions for handling multipart/form-data with SAP Integration Suite. Learn how to set up custom flows and ensure smooth data transmission.

Problems

Inconsistent Line Endings:
- One common issue noted in a blog post on SAP Community is the discrepancy in line endings. It was observed that Postman on Windows creates "correct" line endings, while SAP Integration Suite often generates UNIX line endings, which some APIs cannot handle.
Lack of Built-in Solution:
- Checking the SAP roadmap, there is no built-in solution for this specific problem. You can review the latest updates here.

Solution

When dealing with multipart/form-data in SAP Integration Suite, especially for systems that require strict adherence to standards and can only accept binary data, implementing a solution that meets these requirements can be challenging. Below is a script tailored to address these needs, ensuring proper handling of multipart/form-data with binary data.

The Script

Here's a script to handle multipart/form-data with binary attachments, adhering to RFC 2045 standards:

import com.sap.gateway.ip.core.customdev.util.Message
import java.util.Map
import javax.activation.DataHandler
import java.util.Random
import java.io.ByteArrayOutputStream

// Method to process the data
def Message processData(Message message) {

    // Extract attachments
    Map<String, DataHandler> attachments = message.getAttachments()

    // Check if there are any attachments in the message
    if (attachments.isEmpty()) {
        // No attachments, return the message unchanged or perform other logic
        return message
    } else {
        def bodyBuilder = new ByteArrayOutputStream()
        def boundary = generateBoundary()

        // Iterate through all attachments
        attachments.values().each { attachment ->
            def content = attachment.getInputStream().bytes

            // Ensure boundary is not within the attachment content
            while (new String(content).contains(boundary)) {
                boundary = generateBoundary()
            }

            // Add boundary delimiter
            bodyBuilder.write("--${boundary}\r\n".getBytes())

            // Add attachment headers
            bodyBuilder.write("Content-Disposition: form-data; name=\"file\"; filename=\"${attachment.getName()}\"\r\n".getBytes())
            bodyBuilder.write("Content-Type: application/pdf\r\n".getBytes()) // Adjust the content type as needed
            bodyBuilder.write("\r\n".getBytes())

            // Add the attachment content in binary form
            bodyBuilder.write(content)
            bodyBuilder.write("\r\n".getBytes())
        }
        
        // Closing boundary delimiter
        bodyBuilder.write("--${boundary}--\r\n".getBytes())

        // Set the Content-Type header
        message.setHeader("Content-Type", "multipart/form-data; boundary=${boundary}")

        // Set the message body
        message.setBody(bodyBuilder.toByteArray())

        return message
    }
}

// Method to generate a random boundary
def String generateBoundary() {
    def chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
    def boundary = new StringBuilder("WebKitFormBoundary")
    def rand = new Random()
    (1..16).each {
        boundary.append(chars.charAt(rand.nextInt(chars.length())))
    }
    return boundary.toString()
}

Key Considerations

Binary Data Handling: The script ensures binary data is handled correctly by checking for boundaries within the attachment content and adjusting as necessary. This prevents issues with boundary markers appearing in the binary data.
Boundary Handling: The generateBoundary() method creates a unique boundary string to separate parts of the multipart message. The script includes a check to avoid boundary collisions within the attachment content.
Compliance with RFC 2045: While the script adheres to multipart/form-data standards, it’s important to note that escaping binary data using encoding (like base64) would be more compliant with RFC 2045 for handling non-ASCII data. However, for specific system constraints where binary data is required, this implementation meets those needs.
Error Handling: The script does not include explicit error handling, which is crucial for production environments. Implement proper exception handling to manage issues such as file read errors or boundary generation failures.

Additional Resources

These resources provide valuable information and solutions, but this article presents a practical script to effectively address multipart/form-data challenges.

SAP CPI| Determining Expiring Certificates, Dynamically Updating And Sent Mail Notification

2024-08-05T09:27:39.190000+02:00

Introduction:

The purpose of this blog : To identify certificates in the keystore with less than 30 days remaining until expiration and dynamically update all expiring certificates and send the updated certificate via email.

Prerequired:

SAP BTP and Integration Suite capabilities Cloud Integration.

Cloud Integration Steps:

Firstly, I can trigger the process with a CPI service using POSTMAN or run it based on a time interval with a timer. I will proceed with the timer approach. If you prefer, you can set it to check every 15 days.

Under normal circumstances, we check for expired certificates either when an error occurs in the integration or when we feel the need to verify their expiration status. Our goal is to have one or multiple certificates loaded into the keystore automatically updated at a predetermined time, ensuring that our processes no longer encounter errors due to certificate expiration.

The API we will use: https://{Account Short Name}-tmn.{SSL Host}.{region}.hana.ondemand.com/api/v1/KeystoreEntries

AND

https://{Account Short Name}-tmn.{SSL Host}.{region}.hana.ondemand.com/api/v1/CertificateResources

1-CM_Headers

Our service works with a CSRF token, so we need to obtain the token first. In the initial content modifier, we store the request headers of the service.

2-RR_FetchToken

A defined user must access CPI as an authorized user. After defining security materials, credentials are provided in the flow.

3-RR_KeystoreEntries

4-MM_KeystoreEntries

The left side of the mapping is the XSD we created from the KeystoreEntries OData service. I previously shared information about which fields should be selected. The right side of the mapping is the XSD structure I want to output.

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
	<xs:element name="RootExpiring">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="RootExpiring" maxOccurs="unbounded" minOccurs="0">
					<xs:complexType>
						<xs:sequence>
							<xs:element type="xs:string" name="CertificateNumber" maxOccurs="unbounded" minOccurs="0"/>
							<xs:element type="xs:string" name="CertificateName" maxOccurs="unbounded" minOccurs="0"/>
							<xs:element type="xs:short" name="Validation" maxOccurs="unbounded" minOccurs="0"/>
							<xs:element type="xs:string" name="Type" maxOccurs="unbounded" minOccurs="0"/>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
</xs:schema>

The Groovy script I use to identify certificates with less than 30 days remaining:

def String get30DaysAfter(String arg1){
    
        SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS");
        Date dateNow= new Date()+30

    	return dateFormat.format(dateNow)+"" 
}

5-Router

If there is no certificate that will expire after the mapping, the 'no update' will be observed and the flow will be escalated.

//RootExpiring = ''

6- CM_EscaleteProcess

7-Iterating Splitter

In order to update multiple certificates, we need to split them based on RootExpiring. We will send them to the service one by one.

<RootExpiring>
	<RootExpiring>
		<CertificateNumber>x1</CertificateNumber>
		<CertificateName>a</CertificateName>
		<Validation>2024-02-21</Validation>
		<Type>Certificate</Type>
	</RootExpiring>
</RootExpiring>
<RootExpiring>
	<CertificateNumber>x2</CertificateNumber>
	<CertificateName>b</CertificateName>
	<Validation>2024-02-21</Validation>
	<Type>Certificate</Type>
</RootExpiring>

8-CM_Cert_Inf

It will take the host address from the certificateName field. Therefore, when importing a certificate, we need to give the host address as the alias name.

9-GS_Encoded

import java.security.cert.X509Certificate
import java.util.Base64
import javax.net.ssl.SSLPeerUnverifiedException
import javax.net.ssl.SSLSession
import javax.net.ssl.SSLSocket
import javax.net.ssl.SSLSocketFactory
import com.sap.gateway.ip.core.customdev.util.Message

def processData(Message message) {
    try {
        // Get host and port from message properties
        def host = message.getProperty("host") as String
        def port = message.getProperty("port") as Integer

        def factory = SSLSocketFactory.getDefault() as SSLSocketFactory
        def socket = factory.createSocket(host, port) as SSLSocket

        def session = socket.getSession()
        X509Certificate cert = session.peerCertificates[0] as X509Certificate

        def systemDomainName = cert.issuerDN.name 
        def encodedDERValue = Base64.getEncoder().encodeToString(cert.encoded)

        // Set Properties
        message.setProperty("systemDomainName", systemDomainName)
        message.setProperty("encodedDERValue", encodedDERValue)

        return message
    } catch (SSLPeerUnverifiedException e) {
        throw new Exception("${host} did not present a valid cert.")
    }
}

10-CM_EncodedBody

11-RR_CertificateResources

fingerprintVerified=true:

The true value indicates that the certificate fingerprint has been verified and is valid.

returnKeystoreEntries=false:

This setting determines whether keystore entries will be returned during a process or query. A false value means that the keystore records will not be returned as a result of the operation.

update=true:

if you want to update a certificate or configuration, this setting is set to true.

The CertificateNumber value we keep in the property was mapped with the hexalias field in the mapping. This way, we can obtain the hexalias values resulting from the mapping.

In the next step, there is a classic logging Groovy script.

12-Iterating Splitter

In the next step, I will adjust the fields in the latest build to format my mail properly.

I don't want the RooxExpiring field, which contains unwanted tags in the XML produced from the process call and my mail format. Therefore, I used a splitter and converted the XML to JSON.

Input:

<RootExpiring>
	<RootExpiring>
		<CertificateNumber>x1</CertificateNumber>
		<CertificateName>a</CertificateName>
		<Validation>2024-02-21</Validation>
		<Type>Certificate</Type>
	</RootExpiring>
</RootExpiring>
</RootExpiring>

Output After XML to JSON Converter:

{
	"CertificateNumber": "x1",
	"CertificateName": "a",
	"Validation": "2024-02-21",
	"Type": "Certificate"
}

13-GS_MailBody

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.json.JsonSlurper;

def Message processData(Message message) {
    // JSON body
    def body = message.getBody(java.lang.String) as String;
    
    // Parse JSON
    def jsonSlurper = new JsonSlurper();
    def jsonObj = jsonSlurper.parseText(body);

    // Check if JSON parsing is successful
    if (!jsonObj || !jsonObj.CertificateNumber || !jsonObj.CertificateName || !jsonObj.Validation || !jsonObj.Type) {
        message.setBody("Error: JSON parsing failed or JSON structure is incorrect.");
        return message;
    }

    // Build HTML table row
    def tableRow = """
        <tr>
            <td>${jsonObj.CertificateNumber}</td>
            <td>${jsonObj.CertificateName}</td>
            <td>${jsonObj.Validation}</td>
            <td>${jsonObj.Type}</td>
            
        </tr>
    """

    // Set the HTML body
    def htmlBody = """
        <html>
        <head>
        <style>
            table {
                width: 100%;
                border-collapse: collapse;
            }
            th, td {
                padding: 12px;
                text-align: left;
                border: 1px solid #ddd;
            }
            th {
                background-color: #f2f2f2;
            }
            tbody tr:nth-child(even) {
                background-color: #f9f9f9;
            }
            p {
                color: #000000;
                font-size: 16px;
            }
            h2 {
                color: orange;
            }
        </style>
        </head>
        <body>
            <p><i>Hi there!</i></p>
            <p><i>This email is a validity notification for the certificate details below. Please review the certificate information.</i></p>
            <br>
            <h2>Certificate Information</h2>
            <table>
                <thead>
                    <tr>
                        <th>Certificate Number</th>
                        <th>Certificate Name</th>
                        <th>Validation</th>
                        <th>Type</th>
                    </tr>
                </thead>
                <tbody>
                    ${tableRow}
                </tbody>
            </table>
            <br>
            <p><i>This mail is automatically generated. If you do not receive it properly, please contact your administrator.</i></p>
            <br>
            <i>Thanks & Regards,</i>
            <br>
        </body>
        </html>
    """

    // Set the transformed body
    message.setBody(htmlBody);
    return message;
}

14-Mail Adapter

Let’s give it a try.

There are two expired certificates.

Overview--> Manage Keystore

Deployed flow and Let's check the keystore again.

Mail:

I sent the emails based on the updated certificates. If you want, you can use gather to consolidate them into a single email format.

If no certificates to be updated are found, the flow is escalated.

Automating Job Requisition Updates from Position Object with SAP CPI

2024-08-05T16:52:37.330000+02:00

Introduction

Managing job requisitions efficiently is the lifeblood of any organization's recruitment process. In a dynamic business environment where position data changes frequently, keeping job requisitions updated can be quite the challenge. But what if there was a way to make this process seamless and error-free? That's where SAP Cloud Platform Integration (CPI) and the `JobReqGOPosition` API come into play. In this blog, I’m excited to share how we harnessed these tools to automate job requisition updates and added a nifty feature for HR flexibility.

The Challenge

In any bustling organization, position data is in constant flux—be it due to promotions, role changes, or restructuring. Manually updating job requisitions to reflect these changes can be a painstakingly slow and error-prone process. As a SuccessFactors Consultant working with HR professionals, I know how crucial it is to maintain accurate job requisitions, but I also understand the necessity for occasional manual intervention. Balancing automation with manual control was the puzzle we needed to solve.

The Solution: SAP CPI and JobReqGOPosition API

To tackle this challenge, we turned to SAP CPI and the `JobReqGOPosition` API. This powerful duo ensures that any changes in position data automatically trigger updates in the corresponding job requisitions. Here’s how we crafted this solution, step by step:

Prerequisites

Before diving into the integration process, there are a few prerequisites to ensure smooth implementation:

Enabling std_position_objlist: The `std_position_objlist` must be enabled in the EC system, as it is the core element that the `JobReqGOPosition` API uses to fetch position-related information.
The client should use ‘Position Management’ to create requisitions, and the field for standard position object “std_position_obj” should be configured in the job requisition templates.
The integration was set up to run for full load, i.e., all the requisitions would be updated based on their correspond position related data. In case the recruiter/HR doesn’t want to update any specific requisition, it is recommended to do the following: Adding a "Don’t Process Automatic Changes" Custom Field. By including the custom field "Don’t Process Automatic Changes" in the Job Requisition Templates, recruiters can opt-out of automatic updates for specific requisitions they have manually edited.
Adjusting Mandatory Fields: Some fields in the Job Requisition Templates may need to be made non-mandatory to avoid validation errors during the CPI upsert operation. This adjustment varies from template to template but essentially ensures that any mandatory fields which might be empty at the 'approved' stage do not cause errors.

Step-by-Step Integration Process

1. Fetching Job Requisitions: We configured SAP CPI to fetch job requisitions from Employee Central (EC). The job requisition template includes the custom field "Don’t Process Automatic Changes," allowing HR to opt out of automatic updates for any requisitions they've manually edited. We then proceed to fetch Position Information: Using the `std_position_objlist`, we fetch the latest position data. This standard object list provided all the relevant information needed to keep job requisitions up-to-date. The following image is just an example for the fields we would update, hardcoded for a single requisition. This can be externalized with a manual mode for troubleshooting.

2. Filtering Requisitions: We ensured that any requisitions with the status not as "closed" or “approved” are filtered out, i.e. we are only updating job requisitions which have a status of “closed” or “approved” This has been done to ensure that any field validations due to unfilled pre-approved requisitions do not error out. Their position data would be synced once their status is changed to approved.

3. Message Mapping: To ensure seamless data integration, we used message mapping to format the data correctly before updating EC. Once the position data is fetched, it is fed into the message mapping process as follows:.

4. Updating Job Requisitions: The transformed data is then upserted back to the relevant fields of the `std_position_objlist` in the JobRequisitions API. This ensures that job requisitions are always in sync with the latest position data.

Limitations

While this integration is powerful, it’s important to be aware of certain limitations:

Status of Requisitions: This solution works best for job requisitions in either 'approved' or 'closed' status. Open requisitions that are pending approval might not have all mandatory fields filled in, which can result in errors.
Handling Different Candidate Pools: Care must be taken when expecting a different pool of employees than originally planned. Situations may arise where candidates have applied for a role or location that has since changed, potentially causing confusion or mismatches in expectations.

Benefits of This Approach

Automation: This solution eliminates the need for manual updates, saving precious time and reducing the risk of errors. The integration can be scheduled as per the client’s wish - we recommend to run it every 15 minutes for quick syncing - this means that at max it may take 15 minutes for the requisition to get updated once changes have been made to the relevant position object.
Accuracy: With automatic updates, job requisitions are always aligned with the latest position data.
Flexibility: The custom field "Don’t Process Automatic Changes" allows HR to maintain manual control over specific requisitions when necessary.
Efficiency: By streamlining the recruitment process, we ensure that job requisitions are always current and accurate.

Conclusion

Integrating SAP CPI with the `JobReqGOPosition` API has revolutionized how we manage job requisitions. By automating updates based on position changes and adding a flexible opt-out option for HR, we’ve struck the perfect balance between efficiency and control. This approach not only boosts operational efficiency but also ensures data accuracy and consistency across our HR systems.

If your organization faces similar challenges, consider leveraging SAP CPI and the `JobReqGOPosition` API—along with customized filters—to enhance your recruitment processes. This solution has truly transformed our clients' workflows, and I believe it can do the same for you.

For more detailed information, check out the [SAP Knowledge Base Article] (https://userapps.support.sap.com/sap/support/knowledge/en/2911099).

Filling Headers or Properties Using XSLT Mapping in SAP Cloud Integration

2024-08-06T19:22:18.204000+02:00

Introduction

SAP Cloud Integration is a crucial tool for connecting various systems and applications, enabling seamless data flow and automation. One of the key features it offers is the ability to manipulate message content, headers, and properties using XSLT (Extensible Stylesheet Language Transformations). In this post, we’ll explore how to use XSLT to fill headers or properties, enhancing your integration scenarios.

Understanding XSLT Mapping

XSLT is a language designed for transforming XML documents. In SAP Cloud Integration, it allows for dynamic modifications to messages, including altering headers and properties. This capability is particularly useful for applying conditional logic or handling complex transformations that go beyond simple field mapping.

Filling Headers or Properties

Headers and properties in SAP Cloud Integration serve as essential metadata and custom key-value pairs, respectively. These elements can influence the routing and processing of messages. Using XSLT, you can set these values dynamically based on the message content, making your integration flows more adaptable and powerful.

Step by step guide

To set properties and headers using XSLT, follow these steps:

Specify the Namespace and Import Functions

Define the XSLT stylesheet and include the cpi namespace for functions like setProperty and setHeader.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 xmlns:cpi="http://sap.com/it/" exclude-result-prefixes="cpi" version="2.0">

2. Include the Exchange Parameter

This parameter is essential for setting properties and headers.

<xsl:param name="exchange"/>

3. Define Property and Header Parameters

Import the properties and headers you want to set.

<xsl:param name="myProperty"/>
<xsl:param name="myHeader"/>

4. Create the XSLT Template

Implement a template to set properties or headers based on conditions.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:cpi="http://sap.com/it/" exclude-result-prefixes="cpi" version="2.0">
  <xsl:output method="xml" indent="yes"/>
  
  <!-- include exchange parameter - must for setting props/headers -->
 <xsl:param name="exchange"/>
  
  <!-- define reference to prop/header -->
 <xsl:param name="myProperty"/>
 <xsl:param name="myHeader"/>
  <!-- define template, which wont change body, but set prop/header -->
  <xsl:template match="*">
        <xsl:choose>
          <xsl:when test="contains(//elem1, 'something')">
            <xsl:value-of select="cpi:setProperty($exchange, 'myPropert', 'some')"/>
          </xsl:when>
          <xsl:when test="contains(//elem1, 'somethingElse')">
            <xsl:value-of select="cpi:setHeader($exchange, 'myHeader', 'H1')"/>
          </xsl:when>
          <xsl:otherwise>
            <xsl:value-of select="cpi:setProperty($exchange, 'myPropert', 'Unknown')"/>
            <xsl:value-of select="cpi:setHeader($exchange, 'myHeader', 'Unknown')"/>
          </xsl:otherwise>
        </xsl:choose>
    
    <xsl:copy>
      <xsl:apply-templates select="@* | node()"/>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

5. Alternative Methods

Content Modifiers with XPath can set properties and headers, but they lack the advanced logic capabilities of XSLT.

Common Challenges and Solutions

Working with XSLT can be challenging due to its syntax and the complexity of debugging. Here are some solutions to ease these challenges:

Use an IDE: While integrated development environments (IDEs) like Oxygen XML Editor or Visual Studio Code offer excellent debugging and visualization features, they can sometimes feel bulky and overwhelming, especially for simple tasks.
Online Tools: There are many powerful and convenient online tools for working with XSLT, such as xsltransform.net. These tools allow you to test and refine your XSLT transformations without the need for a full-fledged IDE. They are particularly useful for quick testing and debugging, making them a great choice when you want to avoid setting up a more complex environment.
Start Simple: Begin with basic transformations and gradually introduce more complexity. This approach makes it easier to isolate and fix issues as they arise.
Test Thoroughly: Ensure your XSLT mappings are robust by testing with various input scenarios. This practice helps catch edge cases and unexpected behaviors.

Best Practices

To write efficient and maintainable XSLT mappings:

Modularity: Break complex logic into smaller templates.
Performance: Optimize transformations and avoid redundant calculations.
Security: Validate and sanitize input data, especially for sensitive information.

Conclusion

XSLT mapping in SAP Cloud Integration provides a powerful way to manipulate message content, headers, and properties. This technique offers flexibility and advanced capabilities, making it a valuable tool for complex integration scenarios. Whether you’re setting custom properties or routing messages based on dynamic criteria, XSLT can significantly enhance your integration flows.

DISCLAIMER: This blog post can be found also on my other blog

ServiceNow (SNOW) Integration using Open Connectors in SAP CI

2024-08-07T22:04:25.088000+02:00

Lengthy yet interesting blog! 😊

Contents/Agenda:

Introduction to ServiceNow
Introduction to SAP OpenConnectors
ServiceNow Configuration
OpenConnectors Configuration
SAP CI IFlow Scenario & Steps
Conclusion & Incident Record in ServiceNow

1. Introduction to ServiceNow (SNOW):

What is ServiceNow?
- ServiceNow is a cloud-based platform that provides enterprises IT Service Management (ITSM).
- It is designed to automate and streamline IT service delivery processes.

Key Features:
- Incident Management
- Problem Management
- Change Management, etc.

2. Introduction to SAP OpenConnectors:

What is OpenConnectors?
- Open Connectors are part of the SAP Integration Suite, designed to simplify the process of connecting with third-party applications.
- They provide pre-built, standardized connectors that enables seamless integration.

Key Features:
- Pre-Built Connectors
- Unified API, etc.

3. ServiceNow Configuration:

Log in to the ServiceNow developer (https://developer.servicenow.com/dev.do) portal and create an instance.
You will get the instance URL: https://<instance_name>.service-now.com, Username and Password.
Once the Instance is created and you log in to the ServiceNow tool, your screen should look like below.

In the Filter Navigator search bar, search for OAuth and click on Application Registry.

Now click on New --> Select “Create an OAuth API endpoint for external clients”.

Enter the OAuth details and click on Submit:

Enter the Name.
Enter the Redirect URL: https://auth.cloudelements.io/oauth
Client ID will be auto generated.
⁠Client Secret will be auto generated when you submit the OAuth details.

Note down the Client ID and Client Secret.

Create Users and Groups (assign team members to their respective groups).

4. OpenConnectors Configuration:

Enter the ServiceNow details in the tab below and click on Create Instance.

You will now be redirected the screen below.

The ServiceNow instance is ready, and we can test it. 👆

Click on Instances --> API Docs.

Scroll to the ping section and click on Try it out.

Click on Execute.

You can see the response below. SNOW Instance is reachable from OpenConnectors.

5. SAP CI IFlow Scenario: Create an IFlow using a timer and simple 1:1 mapping for testing convenience.
When the message fails, a ticket will be assigned to CI.
The CI team can then take appropriate actions on the ticket.

Step 1: Use Timer --> To trigger the interface.

Step 2: Set interface priority and Save XML Payload

2.1: In the Content Modifier, set the interface priority under the header.

2.2: Save the XML payload in the message body.

Step 3: Message Mapping: Map source and target fields (1:1). As we are not passing the “heading” field (refer to step 2.2), the mapping will fail.

Exception Subprocess: In the event of mapping failure, the Exception Subprocess will be triggered.

Step 1: Use Error Start Event --> To trigger the Exception Subprocess.

Step 2: Configure the Content Modifier for assigning tickets to different team members.

2.1: Set the header in the content modifier (Ticket assigned to team members).

2.2: Navigate to the message body, set the type as expression and maintain the below XML data.

2.3: In message mapping, map the “assigned to” field using fixValues (maintain the team members under the Advanced tab) mapping function.
Tickets will be assigned to different team members. For example, the first failed message will assign a ticket to the first team member listed in the fixValues.

Maintain the number ranges under Security Material as shown below.

Step 3: Configure Content Modifier for Incident creation

3.1: Set headers in the content modifier as shown below.

3.2: Navigate to the Message Body tab, set the Type as Expression and maintain the provided code as the body (Obtained from OpenConnectors --> Instances --> API Docs --> Scroll to incidents (POST) --> Try it out --> Execute)

Code:

<?xml version="1.0" encoding="UTF-8" ?>
<root>
<active>true</active>
<assigned_to>${header.user}</assigned_to>
<activity_due>${date:now:dd-MM-yyyy HH:mm}</activity_due>
<assignment_group>CPI_Support</assignment_group>
<business_duration>${date:now:dd-MM-yyyy HH:mm}</business_duration>
<caller_id>CPI User</caller_id>
<closed_at>${date:property.CamelCreatedTimestamp+48h}</closed_at>

<description>
Alert Time : ${date:now:dd-MM-yyyy HH:mm} UTC
Message ID : ${property.SAP_MessageProcessingLogID}
Service Name : SAP CI
Interface : ${header.Interface_Name}
**
Error Details : ${header.Error_Details}
Message Details: <Messages: SAP CPI tenant URL>
</description>
<impact>${header.Priority}</impact>
<knowledge>true</knowledge>
<made_sla>true</made_sla>
<opened_at>${date:now:dd-MM-yyyy HH:mm}</opened_at>
<service>CPI Production</service>
<short_description>CPI alert for ${header.Interface_Name}</short_description>
<state>In Progress</state>
<subcategory>Internal Application</subcategory>
<urgency>${header.Priority}</urgency>
<work_start>${date:now:dd-MM-yyyy HH:mm}</work_start>
</root>

Step 4: Convert XML to JSON
Use a converter to change the XML data to JSON since Open Connectors accepts only JSON data.

Step 5: Request Reply to ServiceNow
Use the request reply step to send and receive incident details back from ServiceNow.

Step 6: Configure Open Connectors Adapter.
In the connection tab of Open Connectors adapter, do the configuration as shown below.

How to configure the Credential Name for Open Connectors?
Navigate to the Monitor tab in CI: Monitor --> Manage Security Material --> Create --> User Credentials --> Deploy

Note: Exclude the commas and space while entering the values in user credentials.

Step 7: End the Flow.

Deploy the IFlow: Once deployed, the message will fail in the mapping step, triggering the exception subprocess to send the message OpenConnectors.

6. Conclusion & Incident Record in ServiceNow: With this approach, incident creation is automated based on failures.

A new incident can be seen in ServiceNow.

Thank you very much!

Keep blogging!! 😊 Feel free to post your queries, and I'll be more than happy to help resolve them.

New Pipeline Concept features: new partner id definition, alternative partner, bypass option

2024-08-08T19:28:05.370000+02:00

Here comes another new version 1.0.6 of the Pipeline Concept were we introduced a couple of new features. The package can be accessed from the SAP Business Accelerator Hub. If you have already copied the package to your workspace in your SAP Integration Suite tenant, you can simply run the update of the package to be able to use the latest features.

Upfront, I like to give a warning. We had to introduce an incompatible change of how we define the partner ID to retrieve the Partner Directory parameters, actually this applies to the XSLT for determining the interfaces only. The rest of the Partner Directory definitions are not impacted unless you like to go for the new feature using alternative partner which we would actually recommend.

Before getting into detail for some of the new features, here all new features at a glance:

Revised partner id approach due to lengths restrictions of the partner id
Option to use alternative partner in case of sender wildcard scenarios and to overcome partner id restrictions
Changed default max retry to 5 instead of unlimited retry
For messages in test mode, failed messages are not put into retry
For generic integration flows, adapter parameters were externalized
Option to configure message end event type in case of message stored in dead letter queue, default is Escalated
Option to bypass receiver determination and interface determination steps in case of Point-to-Point pattern
Option to configure a pipeline JMS queue prefix which makes configuration of queue names easier if you create another set of generic integration flow

Furthermore, I like to point you to a new github repository were we describe how to setup the Pipeline for Cloud Integration for a couple of sample scenarios.

New partner ID definition incl alternative partner

Due to the length restriction of the partner ID of 60 characters for retrieving string and XSLT parameters from the Partner Directory, there was a risk of exceeding this limit so that the creation of the Partner Directory entries may fail. This especially applies for IDoc messages where we combine message type, IDoc type and extension type as well as for the partner ID for retrieving the interface Determination XSLT which was a combination of sender component, sender interface and receiver component.

For this reason, we had to change the partner ID definition for retrieving the interface determination XSLT. Furthermore, we introduced the support for alternative partners to generally overcome the length restrictions.

With the alternative partner support, you have the option to map the sender component and the sender interface to a partner ID of your choice, the partner ID might be an integration scenario name. There are lengths restrictions for agency (120 chars), scheme (120 chars) and id (255 chars) as well but in practice it’s very unlikely that you will exceed this. If a message enters the pipeline, we first check if an alternative partner exists, in this case we use the mapped partner ID. Otherwise, the old partner ID approach is used which combines sender component and sender interface separated by ~. So, you can stick to the old approach but you need to ensure that it doesn’t exceed 60 characters.

For the interface determination, we used to define the partner ID as combination of sender component, sender interface and receiver component, all separated by ~. The id was defined as constant string interfaceDetermination. With the new version, we now use the same partner ID like for any other Partner Directory parameters, so either the partner ID from the alternative partner or the combined sender component and sender interface. For the id, we now concatenate the constant string interfaceDetermination and the receiver component separated by underscore _.

Here's an example for better understanding:

Assuming, a message of interface MaterialCreate is sent from sender ABC and routed to two receivers XYZ and UVW. Your scenario is called MaterialMasterReplicate.

We define the alternative partner as follows:

Agency: ABC
Scheme: SenderInterface (this is a fixed string)
Id: MaterialCreate
Pid: MaterialMasterReplicate

For the receiver determination, the key to upload and retrieve the XSLT is as follows:

Pid: MaterialMasterReplicate
Id: receiverDetermination

For the interface determination for receiver XYZ, the key to upload and retrieve the XSLT is as follows:

Pid: MaterialMasterReplicate
Id: interfaceDetermination_XYZ

For the interface determination for receiver UVW, the key to upload and retrieve the XSLT is as follows:

Pid: MaterialMasterReplicate
Id: interfaceDetermination_UVW

The alternative partner approach is not mandatory however we strongly recommend to use this approach for the following reasons:

In practice, it avoids exceeding the lengths restrictions in any case
It groups together all your Partner Directory parameters which belong to the same integration scenario using a meaningful scenario name
It supports sender wildcard scenarios out of the box because it allows to map multiple sender systems to the same partner ID

Before you update your package and re-deploy the generic integration flows, ensure to update your Partner Directory entries accordingly.

See Using the Partner Directory in the Pipeline Concept.

Special case: Point-to-Point scenarios

For Point-to-Point scenarios where we have one sender and one receiver only, we now have the option to bypass the two pipeline steps receiver determination and interface determination which at the end leads to an improved runtime behavior.

In this case, we won't upload the XSLTs to the Partner Directory, instead we need to define two corresponding string parameters receiverDetermination and interfaceDetermination_<receiver name>. Former defines the receiver name, and latter the ProcessDirect endpoint of the scenario-specific outbound processing flow.

For more details, see Special Cases.

Retry handling enhancements

For the retry handling, we have changed the default maximum retry from unlimited to 5. The default applies if you have not maintained a scenario specific maximum retry.

If the maximum retry exceeds, the messages are stored in a dead letter queue. For the standard retry handling you now have the option to configure the message end event type in case of messages stored in the dead letter queue. The default is Escalated. Optionally, you can change the type to Completed.

Furthermore, for messages in test mode, i.e., were the testMode header is true, failed messages are not put into retry, instead they are completed with custom status ErrorInTestMode.

See Standard Retry Handling.

New github repository with sample scenarios

If you like to make yourself familiar with the Pipeline for Cloud Integration and to test the new features that we have recently shipped, check out the Process Integration Pipeline Sample Scenarios github repository.

In the repository, we explain how to setup different sample scenarios using the Pipeline for Cloud Integration. For each sample scenario, an integration package is provided. Furthermore, a Postman collection incl. Postman environment is provided that allows you to setup the Partner Directory entries and to trigger sample messages.

As usually, let me know if you have further ideas, requirements, and feedback, feel free to reach out to me or simply leave a comment.

In the end, I would like to thank my colleagues Mate and Vyacheslav from the Center of Excellence team as well as Daniel from Figaf for their input, a lot of the new features are actually based on their feedback and advise.

What’s New for SAP Integration Suite – June & July 2024

2024-08-09T08:54:52.588000+02:00

This is a continuation of the blogpost series you may find at #WhatsNewInSAPIntegrationSuite. Today you oversee all our impressive updates released within the June and July timeframe. As we have already August, the next update will come very soon. Stay tuned and enjoy the lovely summertime.

Our highlights were:

Accelerate development of integration flows with Generative AI assistance
New adapters available
Creation of new data type and message types
New design guidelines added for the validation of integration flows
Additional adapters for Edge Integration Cell
Simulation support for Edge Integration Cell
API validation policy for API artifacts
Edge Integration Cell on Red Hat OpenShift
Offline availability during periods of temporary connectivity loss
Sizing recommendations for asynchronous messaging
Support for outgoing connections through a HTTP proxy
API anomaly detection reduces security and performance risks
Maintenance of multiple target endpoints through UI
Changes in user interface
Make use of your own global custom codelists in Trading Partner Management
Integrations with trading partners through value-added networks
Support partners with subsidiaries
Improved situational awareness with Event Mesh
Additional data centers for advanced event mesh
Modernization recommendations for on-premise integration scenarios
Updates to the pipeline concept
New rules added to Migration Assessment
Migration tooling is now pattern based
Support for message type objects in migration tooling
New partner content on SAP Business Accelerator Hub
Search and discovery of validated partner use cases on SAP Business Accelerator Hub

Cloud Integration

Accelerate development of integration flows with generative AI assistance

As a first step towards generative AI in our integration area we have extended the design-time tooling in that way that you can create integration flows with the help of generative AI and the unified customer landscape (UCL). Based on your description of a desired integration scenario and existing system instances from UCL, the generative AI tool creates an integration flow with sender and receiver systems. This improves your developer productivity and saves cost. Going forward, we will enhance this offering to include also mediation steps. This feature is only available for tenants with premium edition and as of today in some regions on AWS landscapes. Read the blogpost, watch the demo, and check out the documentation for more information.

New adapters available

We are happy to announce four new adapters in addition to our already rich set of built-in connectivity options. Make use of the new Coupa, NetSuite ERP, Snowflake, and Amazon DynamoDB receiver adapters. All these adapters are available on SAP Business Accelerator Hub and run within the cloud or on the optional Edge Integration Cell runtime.

Creation of new data type and message types

This feature is important for all customers in their journey moving from SAP Process Orchestration to the SAP Integration Suite. You can now import data and message types from the ES Repository along with dependent data types, or create new ones from scratch, or edit existing ones in Cloud Integration by e.g., adding new attributes. These new design time artifacts are stored as XSDs and can be reused in message mapping or in the XML validator flow step. For more information, see the documentation and read the blogpost.

New design guidelines added for the validation of integration flows

Additional design guidelines are added to help you further in designing integration flows in a robust fashion. The new design guidelines include checks to efficiently use scripts, handle security, optimize memory usage, and a few more.

Another new feature is that integration developers may skip a non-compliant design guidelines with consent by providing a reason. This action can also be reverted. See the documentation.

Edge Integration Cell

For running your integration scenarios in your private landscape using the optional hybrid integration runtime Edge Integration Cell runtime we are heavily working on offering you new features and adapters.

Additional adapters

We have increased the set of connectivity options. The following adapters now support also the Edge Integration Cell runtime profile: Amazon Web Services, Microsoft Dynamics 365 CRM, Salesforce, SugarCRM, ServiceNow, Workday, Slack, MS SharePoint, MS Azure Storage, RabbitMQ, and Splunk.

Simulation support

Simulation was a limitation that we had for Edge Integration Cell. Now you may select also the Edge Integration Cell runtime in your designer and run simulations for your integration flows. See the details in our documentation.

API validation policy for API artifacts

We have extended the set of policies. You can now validate incoming messages against an OpenAPI 3.0 Specification using the API validation policy. In the OpenAPI Specification, you can define the expected message headers and query parameters for each API endpoint. See further details in the documentation.

Kubernetes cluster deployment on Red Hat OpenShift

We have extended the set of Kubernetes container application platforms of your choice and you are able now to deploy your Kubernetes cluster on Red Hat OpenShift. Next to the both hyperscaler-based Kubernetes offerings Microsoft AKS and Amazon EKS, you can use SUSE Rancher and Red Hat OpenShift. Alibaba Cloud and Google Kubernetes Engine are on our roadmap. Read the documentation and see note #3247839.

Offline availability during periods of temporary connectivity loss

You can now perform client certificate authentication and authorization for integration flow processing and API proxies in the Edge Integration Cell instance within the customer network. This Edge Local Authentication and Authorization is a fallback to the default cloud-based authentication and authorization in SAP BTP and synchronizes XSUAA security data. Initially, only certificate authentication is supported, further expansion for other OAuth flows and external IDPs are planned. Check out the documentation and note #3472645.

Sizing recommendations for asynchronous messaging

We have updated our sizing guide. Now you get also sizing recommendation for hardware resources in asynchronous messaging scenarios. It calculates CPU and memory requirements depending on number of messages per second and payload sizes. Check out the sizing guide for Edge Integration Cell for further details.

Support for outgoing connections through a HTTP proxy

The Edge Integration Cell runtime now supports you with routing of outgoing connections through a proxy. This is useful if your Edge Integration Cell is part of a network that is using an HTTP proxy to communicate with Edge Lifecycle Management Cloud. Read the documentation.

API-led Integration

API anomaly detection reduces security and performance risks

Since June already you are able to monitor actively an exceptional behavior with the help of the anomaly detection feature of API Management. This AI-based feature helps you to optimize your system performance by identifying irregularities as a sudden spike or drop in API calls, as well as an increase in latency or an increase in the number of detected errors. Patterns that deviate from the normal behavior are visualized and in addition subscribers can be promptly notified through emails to minimize the potential impact of an anomaly and to make sure the issues are addressed in a timely manner. This feature is available with SAP Integration Suite, premium edition and in some data centers. Check out the blogpost and read the documentation.

Maintenance of multiple target endpoints through UI

Previously, the only way to add multiple target endpoints was through API proxy zip update, and policies could only be added to the target endpoint that appeared first in the target endpoints dropdown menu. Now, multiple target endpoints can be added and maintained through the UI, and policies can be added to any target endpoint of your choice using the UI. See the documentation create an API proxy and edit an API proxy.

Changes in user interface

Find the previously named APIs that were located under Monitor in the navigation bar, now renamed to Analyze and located under Monitor and. The functionality remains unchanged.

The classic design of the API business hub enterprise has been removed and is no longer accessible.

B2B Integration

Make use of your own global custom codelists

Important for us to improve your developer efficiency wherever possible. Under Custom Type Systems, you can now create global custom codelists centrally and use them across all artifacts such as MIGs and MAGs. The codelists can be created manually or by uploading a csv file that is based on a standard code list. Refer to the documentation.

Integrations with trading partners through value-added networks

In the B2B Integration area we are happy to tell that we support communications with trading partners through value-added networks (VAN). You can create a new profile type communication partner, which holds the configuration of a VAN provider offering the communication service to trading partners. This profile holds centrally the AS2 partner ID and connection properties which can be used by different templates and agreements. Check out the documentation.

Support partners with subsidiaries

We have introduced Identifier Groups in company and trading partner profiles to enable the assignment of several individual identifiers to a group. This supports scenarios where the agreement are the same across multiple suborganizations of a company and want to use centralized processing with identical mappings. This innovation reduces the need for configuring multiple redundant agreements. The idea is to configure agreements using these identifiers groups, then, at runtime, the associated identifiers will be utilized. Refer to the documentation.

Event-driven Integration

Improved situational awareness with Event Mesh

Since early June already Event Mesh is part of the family. It is targeted for customers with SAP Integration Suite, standard or premium edition, reducing the time to get started with end-to-end event-driven architectures in or beyond the SAP event-driven ecosystem. And it provides the option to combine the event-driven integration with the classic process integration approach. Check out the blogpost and use the access to the Event Mesh documentation.

Additional data centers for advanced event mesh

SAP Integration Suite, advanced event mesh is now available in additional landscapes: on Google Cloud Platform in Europe (Frankfurt) and in US Central and on Amazon Web Service in Brazil (Sao Paulo). See the full list at the SAP Discovery Center.

Migration Assessment and migration tool

Supporting our SAP Process Orchestration customers in their journey to SAP Integration Suite is one of our key investment areas. During last development takts we have released the following innovations:

Modernization recommendations for on-premise integration scenarios

You can now receive modernization recommendations for integration scenarios you are evaluating for a migration from SAP Process Orchestration to SAP Integration Suite. The aim of these recommendations is to improve your integration practice and make use of standardized protocols like SOAP, REST, and OData, modern integration styles such as API-led integrations or event-driven integrations and leverage pre-built integration content from the SAP Business Accelerator Hub. You find the recommendations in a report and in a dashboard after the scenario evaluation. For detailed descriptions, see the modernization recommendations in the migration guide for SAP Process Orchestration and the documentation.

Updates to the pipeline concept

To run integration scenarios on cloud in an asynchronous manner, we had published a documentation how to set up the pipeline concept and offered also a Process Integration Pipeline package on SAP Business Accelerator Hub. The latest version of this package covers custom error handling and improvements of the IDoc inbound processing flow. Furthermore, we have introduced a testMode header to implement your own logic how to deal with messages in test mode.

New rules added to Migration Assessment

We have extended the list of rules applied during evaluation. Now there are rules available that count the number of inbound interfaces, receivers of an integration scenario, determine the number of fields in which file content conversion is used, etc.

A set of characteristics according to which the application evaluates whether an integration scenario can be migrated and what effort you can expect.

Migration tooling is now pattern-based

To cover the migration of much more Integrated Configuration Objects (ICO) and be more generic, our migration tooling has switched from a template-based towards a pattern-based migration approach. Your ICOs need not necessarily match a specific template anymore to be ready for a migration. It is sufficient that the ICO is similar to one of the supported patterns to achieve migration. The migration tooling analyses the ICO that are evaluated as migratable via the Migration Assessment capability and maps it with the patterns. Based on the pattern, it creates an equivalent integration flow in Cloud Integration.

Support for message type objects in migration tooling

As message type and data type objects are available in SAP Integration Suite that you may import or create from scratch, you can now also generate integration flows that contain references to message type and data type objects using the migration tooling. Refer the documentation.

Business Accelerator Hub

Search and discovery of validated partner use cases

We are very excited to announce a new type of accelerator, the content category VPUC on the SAP Business Accelerator Hub. SAP-validated partner use cases are solution packages helping you maximize the return on investment on your SAP BTP venture. Checkout the blogpost read the documentation.

New partner content

Lots of new partner content has been published on SAP Business Accelerator Hub by Kaar Technologies, PiLog, Coveo, Qintesi, Crave InfoTech, Tarento, Wipro, KPMG, Twenty5, and RealCore. Check out the blogpost explaining all the details.

How to stay tuned to recent and upcoming innovations?

The SAP Road Map Explorer is your one-stop shop for all SAP Integration Suite innovations. You can easily check out the latest innovations and follow what is planned for the following quarters. All recent innovations also cover under the tab Features further links to blogposts or documentation.

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

And if you have not heard of our monthly webinars, I suggest you sign up to get an invitation to the upcoming ones. Our team of Product Management experts host these webinars and showcase the latest and greatest updates regarding all SAP Integration Suite capabilities. The webinars take place on the last Tuesday of every month and the next one is already scheduled for August 27th.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, presentations, and Q&As.

Are you aware of the Release Navigator for SAP BTP? It consolidates release information across SAP BTP products and services easing you the way to find product release related notes, blogposts, and webpages. For your convenience use the direct link to the SAP Integration Suite section of the Release Navigator.

Enhancing SAP CPI with Custom Payload Logging using S4HANA On Prem and a UI5 Dashboard

2024-08-09T15:22:35.731000+02:00

In the dynamic world of SAP Cloud Integration (CPI), efficient logging mechanisms are crucial for maintaining robust and reliable integration processes. While CPI offers various built-in options for message monitoring and logging, these may not always meet specific project requirements. In this blog, we will explore a custom logging approach that empowers developers to capture and manage payloads more effectively. There are various logging options already available by using Groovy scripts, Data Stores, and external logging services like Splunk.

However, we will try to create a tailored logging solution that enhances visibility and troubleshooting capabilities within your CPI environment, utilizing the existing SAP OnPrem solution in your landscape. Join me as we get into the details of this custom strategy, designed to optimize your integration workflows.

Prerequisites-

CPI Subscription – NEO or CF
S4HANA On Prem
WebIDE or BAS

Limitations-

Can only log one payload per Iflow as per the current design. This can be further extended to support multiple step payloads in the upcoming versions.
Only Supports logging and display of XML, JSON and CSV payloads for now.

The below solution diagram gives you a holistic view of the applications involved in this design and their roles in each of the steps.

Solution Diagram-

Overall Steps-

CPI Logger Iflow to call an Inbound Proxy – This Iflow can be called by any Iflow in your CPI tenant which needs to log its payload.
Inbound Proxy to save payload to AL11 – This Inbound proxy will be called by the CPI Logger Iflow to save the payload to an AL11 directory in S4HANA On Prem
CPI Dashboard to consume CPI’s Monitoring API and to display the payload – The UI5 app connects to CPI monitoring service to read and display a monitoring overview screen (much like the traditional SAP PO). It then allows you to open any individual message and display the corresponding payload of the message. This uses a standard set of APIs which allows the UI5 dashboard App to fetch the CPI monitoring data
OData Service to enable our CPI Dashboard app to read the payload from AL11 directory – This OData service will enable you to read any given AL11 payload using its Message GUID as an input.

This is how the end solution will look like-

Open the CPI Dashboard UI5 app and search for an overview of messages within a given time period and click on the resultant row with Iflow (ZPayloadLogger_Src) whose payloads you want to view.

XML Payload-

This will open a list of all the messages for that Iflow within that given period. Click on the first row.

This will take you to a new page which will display the Iflow Name and the Message GUID. The payload will then be displayed in a text area below. You also have an option to download the payload using the “Download Payload” button. This is an example of an XML payload.

Below is how the JSON and CSV payloads will be displayed-

JSON-

CSV-

If a certain CPI Iflow isn’t using this functionality to log its payload-

GIT Repository of the CPI Dashboard App-

Git Repo for Dashboard App - NEO

Please note that the above project has been built in WebIDE for NEO. I have created a Repository for Cloud Foundry as well. You can modify the xs-app.js and mta.yaml files with your respective destination references-

Git Repo for Dashboard App - CF

You are welcome to suggest improvements and new features in the App as you explore it.

We will now go through all the building blocks of this application-

Steps 1 and 2 – CPI Iflow calls an SAP Inbound Proxy and this proxy program saves the payload in the AL11 directory

Inbound Proxy Program to be called by CPI-

The inbound proxy program will be consumed by CPI to send payloads to be logged from CPI into SAP. The program saves the received payloads in a predefined AL11 directory with <MessageGUID>.<Extension> format as shown in the below screenshot.

Inbound Proxy Program Details-

Service Provider-

Implementing class-

Implementing method-

Inbound Proxy Code-

The below Inbound proxy code accepts Message GUID and Payload type as inputs from the consumer (ZPayloadLogger Iflow in our case) and calls the Function module Z_SAVE_PAYLOAD_AL11 which saves the payload to the predefined AL11 directory path.

method zii_si_cpipayload_logger_in~cpipayload_logger.
*** **** INSERT IMPLEMENTATION HERE **** ***

    data: lv_result type string,
          lv_payloadcontent type string,
          lv_filename type string.

    data: lv_start_index type i,
        lv_end_index type i,
        lv_cdata_length type i,
        lv_cdata_tag type string.

    data: msg_guid     type c length 50,
          payload_type type c length 30.


loop at input-mt_cpipayload-payload into data(lv_payload).

  lv_filename = lv_payload-message_guid && '.' && lv_payload-payload_type.

  call function 'Z_SAVE_PAYLOAD_AL11'
  exporting
    lv_payload_data = lv_payload-payload_content
    lv_filename = lv_filename
  importing
    lv_status = lv_result.

  msg_guid = lv_payload-message_guid.
  payload_type = lv_payload-payload_type.

     endloop.

  endmethod.

Function Module – Z_SAVE_PAYLOAD_AL11

FUNCTION Z_SAVE_PAYLOAD_AL11.
*”----------------------------------------------------------------------
*”*”Local Interface:
*”  IMPORTING
*”     REFERENCE(LV_PAYLOAD_DATA) TYPE  STRING
*”     REFERENCE(LV_FILENAME) TYPE  STRING
*”  EXPORTING
*”     REFERENCE(LV_STATUS) TYPE  STRING
*”----------------------------------------------------------------------

DATA: lv_file_path TYPE string,
            lv_directory TYPE string.

  “ Set the directory path where the file will be saved
  lv_directory = ‘<Your AL11 Filepath>’.

“ Concatenate the directory path and file name
  CONCATENATE lv_directory lv_FILENAME INTO lv_file_path.

  OPEN DATASET lv_file_path FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

 TRANSFER lv_payload_data TO lv_file_path.

 CLOSE DATASET lv_file_path.

  “ Check if the file was successfully saved
  IF sy-subrc = 0.
    lv_STATUS = ‘Payload saved to AL11 directory:’.
  ELSE.
    lv_STATUS = ‘Failed to save payload to AL11 directory.’.
  ENDIF.

ENDFUNCTION.

Expected Payload by Inbound Proxy- (Data under xml element “PayloadContent” can either be xml, json or csv) –

Below is an example of an xml payload that can be sent into the Inbound proxy from CPI’s Iflow.

<n0:MT_CPIPAYLOAD xmlns:n0='http://sap.com/Basis/CustomFields/Generated/*'>

  <Payload>

    <PayloadContent><![CDATA[    <test>

      <Field1>Value2</Field1>

      <Field2>Value3</Field2>

      <Field3>Value4</Field3>

    </test>]]></PayloadContent>

    <MessageGUID>521100b2-66e4-4f39-b4c5-451cfaab057d</MessageGUID>

    <PayloadType>XML</PayloadType>

  </Payload>

</n0:MT_CPIPAYLOAD>

CPI Flows

We have 2 CPI flows here,

ZPayloadLogger_Src – This represents any source flow which wants to log its payload by referring its Message GUID.
ZPayloadLogger – This represents the actual CPI logger flow which can be called by any Iflow in your landscape (like ZPayloadLogger_Src flow) that wants to log its payload.

Expected Input Payload into ZPayloadLogger Flow:

Consumers of this Iflow are required to simply send the payload in XML, JSON or CSV format within the request body and pass the below 2 headers-

1. MessageGUID

2. PayloadType

ZPayloadLogger_Src IFlow

As shown above, the original Iflow (ZPayloadLogger_Src) which wants to log its payload, needs to capture it’s MessageID using camel header “SAP_MessageProcessingLogID” and then send it in the message header to the CPI Logger Flow (ZPayloadLogger). It also needs to send a header called “PayloadType”, which can be xml, json or csv, depending on the type of the body sent to ZPayloadLogger IFlow.

ZPayloadLogger IFlow-

XI Channel connecting to S4HANA OnPrem via Cloud Connector-

Below are the key channel configurations-

Refer below blog for more details on how to connect CPI to SAP OnPrem via Proxy method-

Cloud Integration - Configuring scenario using the XI receiver adapter

Script to construct the expected Inbound Proxy Payload-

The below Groovy script within the ZPayloadLogger Iflow constructs the payload required by the Inbound Proxy program.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.MarkupBuilder

def Message processData(Message message) {
    //Get headers
    def headers = message.getHeaders()
    def messageGuid = headers.get("MessageGUID")
    def payloadType = headers.get("PayloadType")

    //Get payload content from message body
    def payloadContent = message.getBody(String)

    //Create XML structure
    def writer = new StringWriter()
    def xml = new MarkupBuilder(writer)
    xml.'n0:MT_CPIPAYLOAD'('xmlns:n0': 'http://sap.com/Basis/CustomFields/Generated/*') {
        Payload {
            PayloadContent {
                mkp.yieldUnescaped "<![CDATA[$payloadContent]]>"
            }
            MessageGUID(messageGuid)
            PayloadType(payloadType)
        }
    }

    // Set the output message body
    message.setBody(writer.toString())

    return message
}

Step 3 – Consuming CPI’s monitoring API from CPI Dashboard App

Below is the CPI monitoring API endpoint to fetch all the monitoring logs into the UI5 app.

“/v1/MessageProcessingLogs”

Below is the link to the Business Accelerator Hub which gives an in-depth API reference and guidelines to consume it.

Reference - https://api.sap.com/api/MessageProcessingLogs/resource/Logs

Destination service in BTP-

Below is the destination that needs to be created in BTP to connect to the CPI service.

Then, refer this destination within your neo-app.json (NEO) or xs-app.json (CloudFoundry) file of the UI5 app.

Step 4 – OData service to be called by the UI5 Dashboard App to get the saved payloads using MessageGUID

The payloads stored in AL11 directory need to be accessed by our CPI Dashboard app. For this reason, we will create a Function module which takes MessageGUID as an input and returns the resultant payload from the AL11 directory.

Function Module Code-

The below code accepts Message GUID as an input and responds back with the Payload and Filetype.

FUNCTION Z_GET_PAYLOAD.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(LV_GUID) TYPE  STRING
*"  EXPORTING
*"     VALUE(LV_PAYLOAD) TYPE  STRING
*"     VALUE(LV_FILETYPE) TYPE  STRING
*"----------------------------------------------------------------------

DATA:
  lv_al11filepath TYPE string,
  lv_line TYPE string,
  lv_dir TYPE eps2filnam,
  p_file_n TYPE localfile,
  lv_extension TYPE string,
  lv_valid_extension TYPE abap_bool,
  lv_extensions TYPE TABLE OF string.

lv_dir = '<AL11 Directory Path>'.

lv_PAYLOAD = ''.

APPEND 'csv' TO lv_extensions.
APPEND 'json' TO lv_extensions.
APPEND 'xml' TO lv_extensions.

LOOP AT lv_extensions INTO lv_extension.
  lv_al11filepath = lv_dir && lv_guid && '.' && lv_extension.

  p_file_n = lv_al11filepath.

  OPEN DATASET lv_al11filepath FOR INPUT IN TEXT MODE ENCODING DEFAULT.
  IF sy-subrc = 0.
    lv_filetype = lv_extension.
    lv_valid_extension = abap_true.

    DO.
      READ DATASET p_file_n INTO lv_line.
      IF sy-subrc <> 0.
        EXIT.
      ENDIF.
      lv_PAYLOAD = lv_PAYLOAD && lv_line && cl_abap_char_utilities=>cr_lf.
    ENDDO.

    CLOSE DATASET p_file_n.
    EXIT.
  ENDIF.
ENDLOOP.

IF lv_valid_extension <> abap_true.
  lv_PAYLOAD = 'No valid file found'.
ENDIF.

IF sy-subrc <> 0.
  lv_PAYLOAD = 'Error occurred while reading file'.
ENDIF.

ENDFUNCTION.

Next step is to expose this Function module as an OData service, which will then be consumed by our Dashboard App. You can follow the below blog for your reference for this.

Steps to build an RFC based OData service with multiple selection values

This is a screenshot of how your generated OData service will look-

Testing the OData service giving Message GUID as a reference-

The xml payload is returned in response to the OData request call.

Below is the destination service configuration in BTP to connect to this OData service-

Then, reference the above destination within your neo-app.json (NEO) or xs-app.json (CF) file as shown below-

As shown above, once all the steps shown in the Solution Diagram are implemented, you should be able to run your Dashboard app and view payloads of IFlows that are using this functionality.

Demo-

Now that we have completed all the required configurations, we will go ahead and demonstrate the functionality using a message triggered from Postman client.

Send a sample xml payload using Postman client to the endpoint of ZPayloadLogger_Src Iflow in CPI-

Message processed as per CPI message monitor- Note that ZPayloadLogger_Src is the actual flow whose payload we want to log, whereas ZPayloadLogger flow is the one which calls our Inbound Proxy program to store the payload within SAP’s directory.

Inbound proxy message processed successfully in SAP-

Payload content in SAP- Shows the actual xml file within CDATA tag.

File saved in AL11 directory-

XML content displays as expected in AL11 directory-

CPI Dashboard App – Displays 2 messages in overview page. Click on ZPayloadLogger_Src.

This opens the message monitor window. Notice that the Message GUID matches the one from our CPI and SAP monitoring screens. Click on the message.

This opens the message details page which finally displays our XML message.

Message displayed on successfully downloading the message.

Click on the downloaded payload-

Payload displayed in our xml editor-

We now arrive at the end of this blog post. This solution effectively addresses the need for efficient payload extraction in CPI, offering a practical and user-friendly tool for integration monitoring. The integration of CPI, ABAP, and UI5 showcases a comprehensive approach, leveraging the strengths of each technology to create a cohesive solution.

Comments and suggestions for improvement are welcome.

Essential Groovy Script Solutions for SAP Cloud Integration

2024-08-13T08:59:24.938000+02:00

Introduction:

In SAP Cloud Integration (CI and formerly known as CPI), Groovy scripts play a crucial role in customizing and fine-tuning integration flows. Whether you're manipulating XML structures, handling data transformations, or performing complex validations, Groovy scripts provide the flexibility you need. In this blog post, I’ll share several essential Groovy script solutions that address common challenges in SAP CI. These scripts, which you can integrate into your flows, include logic for sorting XML segments, managing data formats, and more.

1. Sorting XML Segments in an IDoc

When working with IDocs in SAP CI, the order of segments can be critical. This first script ensures that specific segments within an IDoc are sorted correctly according to a predefined order.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.XmlUtil
import groovy.xml.StreamingMarkupBuilder

def Message processData(Message message) {
    def body = message.getBody(java.lang.String) as String
    def xml = new XmlSlurper().parseText(body)

    // Define the desired order of segments
    def desiredOrder = [
        'EDI_DC40',
        'ZAP2PO_MESSCONTRO',
        'ZAP2PO_OPTIONS',
        'ZAP2_POHEADER',
        'ZAP2_POITEM',
        'ZAP2_POACCOUNT',
        'ZAP2_POACCOUNTPROFITSEGMENT',
        'ZAP2_POSCHEDULE'
    ]

    // Ensure xml.IDOC is a Node and get its children
    def idocNode = xml.IDOC[0]
    def sortedChildren = idocNode.children().sort { a, b ->
        desiredOrder.indexOf(a.name()) <=> desiredOrder.indexOf(b.name())
    }

    // Rebuild the IDOC element with sorted children
    def builder = new StreamingMarkupBuilder()
    def sortedXml = builder.bind {
        ZAP2POCREATE {
            IDOC(BEGIN: '1') {
                sortedChildren.each { child ->
                    mkp.yield child
                }
            }
        }
    }.toString()

    // Set the sorted XML back to the message body
    message.setBody(sortedXml)

    return message
}

Explanation:

This script parses an incoming XML, sorts the segments within an IDoc according to a predefined order, and reconstructs the XML to ensure that downstream systems receive it in the expected format.

2. Replacing the Root Node of an XML Payload

Sometimes, you may need to replace the root node of an XML document to conform to a new schema or to meet specific integration requirements. The following Groovy script shows how to replace the root node of an XML payload in SAP CI.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.StreamingMarkupBuilder
import groovy.xml.XmlUtil

def Message processData(Message message) {
    def body = message.getBody(java.lang.String) as String
    def xml = new XmlSlurper().parseText(body)

    // New root node name
    def newRootNodeName = 'NewRootNode'

    // Build the new XML structure with the new root node
    def builder = new StreamingMarkupBuilder()
    def newXml = builder.bind {
        "${newRootNodeName}" {
            xml.children().each { child ->
                mkp.yield child
            }
        }
    }.toString()

    // Set the new XML back to the message body
    message.setBody(newXml)

    return message
}

#1 Test Execution result

2.a.groovyIDE_link

#contiva IDE tool

If you need to change the root element from <ZAP2POCREATE> to <NewRootNode>, this script makes it easy and efficient to handle such transformations within your SAP CI flows.

3. Remove XML Declaration

When working with XML documents in Groovy, you might need to remove the XML declaration, especially if you're processing the XML further or integrating it with other systems. The XML declaration can vary in format, including different cases for encoding, the use of single or double quotes, or even omitting the encoding attribute altogether.

XML declaration types:

Spoiler

<?xml version="1.0" encoding="UTF-8"?>
<?xml version='1.0' encoding='UTF-8'?>
<?xml version="1.0" encoding="utf-8"?>
<?xml version='1.0' encoding='utf-8'?>
<?xml version="1.0"?>
<?xml version='1.0'?>

<?xml version="1.0" encoding="UTF-8"?><?xml version='1.0' encoding='UTF-8'?><?xml version="1.0" encoding="utf-8"?><?xml version='1.0' encoding='utf-8'?><?xml version="1.0"?><?xml version='1.0'?>

Here’s a Groovy script that handles all these variations:

import com.sap.gateway.ip.core.customdev.util.Message;
import groovy.xml.XmlUtil;
import groovy.xml.MarkupBuilder;
import java.util.HashMap;
import java.util.Map;
import groovy.xml.StreamingMarkupBuilder;

def processData(Message message) {
    def body = message.getBody(java.lang.String) as String
    
        // Regular expression to match all variations of the XML declaration
        //Use (?i) within the regular expression to make it case-insensitive
    def xmlDeclarationPattern = /(?i)<\?xml.*version\s*=\s*['"]1\.0['"](.*encoding\s*=\s*['"](utf-8)['"])?\s*\?>/
    
    // Remove the XML declaration
    body = body.replaceAll(xmlDeclarationPattern, "")
    
    message.setBody(body) // Set the modified XML back to the message body
    return message
}

4. Mapping with Groovy - XML Input and XML Output

Using groovy to transform XML input into a custom XML output.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.MarkupBuilder

def Message processData(Message message) {
    // Get the XML input as a string
    def body = message.getBody(String)
    def inputXml = new XmlSlurper().parseText(body)

    // Initialize StringWriter to hold the new XML content
    def writer = new StringWriter()
    def xmlBuilder = new MarkupBuilder(writer)

    // Handle single records ( 'Records' elements)
    xmlBuilder.root {
        User {
            firstName(inputXml.Records.name1.text())
            lastName(inputXml.Records.name2.text())
            email(inputXml.Records.mailaccount.text())
            phone(inputXml.Records.mailaccount.text())
            recordtype("User Account")
        }
    }
    
     //Handle unbounded records (multiple 'Records' elements)
   /** xmlBuilder.root {
        inputXml.Records.each{ recData ->
            User {
                firstName(recData.name1.text())
                lastName(recData.name2.text())
                email(recData.mailaccount.text())
                phone(recData.mailaccount.text())
                recordtype("User Account")
            }
        }
    } **/
    

    // Set the generated XML as the message body
    message.setBody(writer.toString())
    return message
}

#1 Test Execution - when the input contains one record

#2 Test Execution - when the input contains multiple records

4.a.groovyIDE_link

5. Mapping with Groovy - JSON Input and JSON Output

Using groovy to transform XML input into a custom JSON output.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.json.JsonSlurper
import groovy.json.JsonBuilder

def Message processData(Message message) {
    // Get the JSON input as a string
    def body = message.getBody(String)
    def inputJson = new JsonSlurper().parseText(body)

    // Initialize a map to build the new JSON content
    //Handle single record 
  /*  def jsonContent = [
        record: [
            firstName : inputJson.root.Records.name1,       //if input json is an error, even if it has one record, then define like this "inputJson.root.Records[0].name1"
            lastName : inputJson.root.Records.name2,
            email : inputJson.root.Records.mailaccount,
            phone : inputJson.root.Records.mailaccount,
            recordtype : "User Account"
        ]
    ]*/
    
    //Handle muliple records (multiple 'Records' elements)
    // Create a list to hold the JSON records
    def jsonRecords = []
    
    // Iterate over each <Records> element and build JSON objects
    inputJson.root.Records.each { record ->
        def jsonRecord = [
            firstName: record.name1,
            lastName: record.name2,
            email: record.mailaccount,
            phone: record.contactnumber,
            recordtype : "User Account"
        ]
        jsonRecords << jsonRecord
    }
    def jsonBuilder = new JsonBuilder(jsonRecords)

    // Set the generated JSON as the message body
    message.setBody(jsonBuilder.toPrettyString())
    return message
}

#1 Test Execution - when the input contains one record

#2 Test Execution - when the input contains multiple records

5.a.groovyIDE_link

Scripts 4 and 5 can be interchanged or customized as needed.

Conclusion:

In this blog post, we’ve covered several essential Groovy script solutions that address common challenges in SAP CI.

Feel free to adapt these scripts to your specific integration needs, and don’t hesitate to reach out if you have any questions or suggestions for additional topics!

SAP Integration Suiteを使ってSAP Datasphereからデータを抽出する方法 OData編

2024-08-15T10:19:34.554000+02:00

はじめに

SAP の連携ツールである SAP Integration Suite を使用して SAP Datasphere からデータを抽出するには、以下の2つの方法があります。本ブログでは①の方法について紹介します。

① SAP Datasphere の OData サービスを利用したデータ抽出(本ブログ)

② SAP Datasphere データベースユーザでの JDBCを利用したデータ抽出(次回ブログにて記載予定)

今回は下記のバージョンで検証を行いました。
SAP Datasphere : バージョン2024.16.46
SAP Integration Suite : バージョン 3.66.0

手順

SAP Datasphere で OAuth クライアントを作成する
SAP Integration Suite で OAuth2 Authorization Code を作成・認証する
SAP Integration Suite で Integration Flow を作成する
SAP Integration Suite で Integration Flow をデプロイする
SAP Integration Suite で Integration Flow の動作を確認する

ポイント

SAP Datasphere が 3-legged OAuth 2.0 であるため、SAP Integration Suite 側で OAuth2 Authorization Code を作成する必要があります
SAP Datasphere で作成する OAuth クライアントの用途は「インタラクティブ用途」を設定します
SAP Datasphere には、OAuth2 Authorization Code 認証時の SAP Datasphere ユーザでアクセスするため、当該ユーザが参照できる範囲のオブジェクトのデータが抽出できます

ここから具体的な方法を紹介します。

手順1.SAP Datasphere で OAuth クライアントを作成する

1.SAP Datasphere にログインします

2.トップページのナビゲーションバーからシステム > 管理を選択します

3.[アプリ統合] タブをクリックします

4.OAuth クライアントの [+ 新規 OAuth クライアントを追加] をクリックします

5.以下の情報を入力し、[追加] ボタンをクリックして OAuth クライアントを作成します

名称: 任意のOAuth クライアントの名称（この例では Cloud_Integration）
目的: インタラクティブ用途を選択
リダイレクト URI: https://<hostname>/itspaces/odata/api/v1/OAuthTokenFromCode
（Token Service が Authorization Code を返す（リダイレクトする） SAP Cloud Integration の URI）

参考: OAuth 2.0 Authorization Code Grant

6.[シークレットコードをコピー] ボタンをクリックしてクリップボードにコピーしたクライアントシークレットをメモ帳などにコピーしておきます

7.併せて “OAuth クライアント ID” もメモ帳などにコピーしておきます

8.[アプリ統合] タブの OAuth クライアントに表示されている “権限 URL” と “トークン URL” もメモ帳などにコピーしておきます

手順2.SAP Integration Suite で OAuth2 Authorization Code を作成・認証する

1.SAP Integration Suite にログインします

2.Monitor > Integrations and APIs をクリックします

3.Security Material のタイルをクリックします

4.[Create] をクリックして表示されるコンテキストメニューから [OAuth2 Authorization Code] を選択します

5.Create OAuth2 Authorization Code ダイアログで以下の情報を入力し、[Deploy] ボタンをクリックします

Name: 任意の名称（この例では Datasphere_AuthCode）
Provider: Generic を選択
Authorization URL: SAP Datasphere の認証 URL（前の手順でコピーしたもの）
Token Service URL: SAP Datasphere のトークン URL（前の手順でコピーしたもの）
Client ID: SAP Datasphere で作成した OAuth クライアントのクライアント ID（前の手順でコピーしたもの）
Client Secret: SAP Datasphere で作成した OAuth クライアントのクライアントシークレット（前の手順でコピーしたもの）
Send As: Body Parameter を選択
User Name: SAP Datasphere のログインユーザ名
Scope: 空白で OK

作成した OAuth2 Authorization Code の Status が Unauthorized になっているので、認証をおこないます

6.作成した OAuth2 Authorization Code の　[More] ボタン( ... )をクリックして表示されるコンテキストメニューから [Authorize] を選択します

7.Information ダイアログで内容を確認し、[OK] ボタンをクリックします

8.SAP Datasphere のログオン画面で、ユーザ名とパスワードを入力して [ログオン] ボタンをクリックします

9.認証成功のメッセージを確認します

10.OAuth2 Authorization Code の Status が Deployed になっていることを確認します

手順3.SAP Integration Suite で Integration Flow を作成する

1.SAP Integration Suite のホームページから Design > Integrations and APIs をクリックします

2.[Create] ボタンをクリックしてコンテンツパッケージを作成します

3.以下の情報を入力して [Save] ボタンをクリックします

Name: 任意のパッケージ名（この例では Datasphere_OData_Integration）
Technical Name: Name の内容から自動設定
Short Description: 任意の概要説明

4.Artifacts タブに移動します

5.Add をクリックして表示されるコンテキストメニューから [Integration Flow] を選択します

6.Add Integration Flow ダイアログで以下の情報を入力し、[Add] ボタンをクリックします

Create を選択
Name: 任意の Integration Flow 名（この例では Datasphere_Odata_iFlow）
ID: Name から自動入力
Runtime Profile: Cloud Integration
Description: 任意の説明
Sender: 空白
Receiver: 空白

デプロイ時に一回だけ起動し、SAP Datasphere からデータを取得する Integration Flow を作成します

7.Artifacts から追加した Integration Flow を選択します

8.右のような Integration Flow を作成します

Request Reply から Receiver への接続では、[HTTP] を選択します

9.Groovy Script の Processing タブをクリックします

10.Script File の [Select] ボタンをクリックします

11.Select Resource ダイアログで、Local Resources タブをクリックして、[Upload from File System] ボタンをクリックします

12.次のコードが記述されている Groovy Script ファイルをアップロードします(エディタ上で直接コードを記述することも可能です)

8行目の "Datasphere_AuthCode" 部分には前の手順で作成したOAuth2 Authorization Code 名を入れてください

import com.sap.gateway.ip.core.customdev.util.Message;
import com.sap.it.api.securestore.SecureStoreService;
import com.sap.it.api.securestore.AccessTokenAndUser;
import com.sap.it.api.securestore.exception.SecureStoreException;
import com.sap.it.api.ITApiFactory;
def Message processData(Message message) {
    SecureStoreService secureStoreService = ITApiFactory.getService(SecureStoreService.class, null);
    AccessTokenAndUser accessTokenAndUser = secureStoreService.getAccesTokenForOauth2AuthorizationCodeCredential(“Datasphere_AuthCode");
    String token = accessTokenAndUser.getAccessToken();
    message.setHeader("Content-Type", "application/json");
    message.setHeader("Authorization", "Bearer "+token);
    def messageLog = messageLogFactory.getMessageLog(message);
    if (messageLog != null) {
        messageLog.setStringProperty("logging#1", "accessTokenAndUser=" + accessTokenAndUser.toString()); 
        messageLog.setStringProperty("logging#2", "token=" + token); 
    }
    return message;
}

13.HTTP の Connection タブをクリックし、以下の情報を入力します

Address: データを取得する SAP Datasphere の OData API
Query: OData API をコールするときのクエリパラメータ
Proxy Type: Internet を選択
Method: GET を選択
Authentication: None を選択
Request Headers: Authorization　（必須）
Response Headers: *

※データを取得する SAP Datasphere の OData API については、こちらのヘルプページをご参照ください。今回はアクセス可能なスペースを一覧で取得するOData APIを利用したため、 https://<tenant_url>/api/v1/dwc/catalog/assets　としています。

手順4.SAP Integration Suite で Integration Flow をデプロイする

1.[Save] ボタンをクリックします

2.[Deploy] ボタンをクリックします

3.Confirmation ダイアログで Runtime Profile でCloud Integrationを選択して、[Yes] ボタンをクリックします

4.Deployment ダイアログで [OK] ボタンをクリックします

5.Deployment Status タブをクリックし、Deployment Status と Runtime Status を確認します

6.Navigate to Manage Integration Content リンクをクリックします

7.Manage Integration Content 画面で実行状態を確認します

8.Integration Flow の実行をトレースするためにLog Configuration の Log Level を Trace に変更します

9.Integration Flow の Edit 画面で再度 [Deploy] ボタンをクリックし、Integration Flow をデプロイします

手順5.SAP Integration Suite で Integration Flow の動作を確認する

1.Monitor > Integrations and APIs をクリックします

2.Monitor Message Processing の All Artifacts タイルをクリックします

3.作成・デプロイした Integration Flow を選択します

4.Logs タブをクリックし、Log Level の Trace リンクをクリックします

5.Run Steps の End をクリックします

6.Message Content をクリックします

7.Payload タブをクリックして、データが取得できていることを確認します（JSON 形式）

以上ですべての手順が完了しました。最後までお読みいただきありがとうございました。

Special thanks to Ikeguchi Daisuke-san!

SAP Integration Suite - Connect Shopify and Integration Suite over webhooks

2024-08-23T09:09:51.067000+02:00

So you decided to leave your IT job and sell your home-made candles online?

Chances are you are doing so through an online business platform such a Shopify.

But as you business grows, you need to integrate your Shopify shop with other systems such as an ERP. And this is my job: explaining you how to do so!

This can be achieved using SAP BTP Integration Suite and we'll see how to do that in this blog, especially how to connect the Shopify Webhook to a Cloud Integration integration flow.

In this blog, we will assume that you know the SAP Business Technology Platform (BTP) and the Integration Suite - a least from a basic perspective.

Setting the scene

Cloud-native solutions such as Shopify often provide webhooks which let you call a REST API when a specific event happens. This is perfect to call an integration flow that will process the Shopify data.
However, webhooks are not very good at security. Hence we will need to use both API Management and Cloud Integration to implement the pilot.

What do we need?

First of all, the scenario will need data massage.
Indeed, the data coming from Shopify cannot be used "as-is" in S/4HANA since the data structure is completely different. This is done in an integration flow in the Cloud Integration capability (but will not be part of this blog). Also, if you connect to another system than S/4HANA, you may need connectivity using out-of-the-box Cloud Integration Adapters.

Secondly, the scenario will need specific security features.
Indeed, Shopify webhooks have no way to authorize against the target API and the webhook sends the full payload when triggered. API Management capability can come to the rescue: it sits between the consumer and the API implementation (ie. Shopify webhook and integration flow) and can receive non-authorized requests and perform further security checks.

Let's implement all that in the next steps!

Technical implementation

Setting up Cloud Integration

The integration flow that will be called by Shopify's webhook will be very simple: it will be exposed as REST API and will eventually contain the mapping to the backend system (eg. S4).

Start by creating an integration flow in the package of your choice. I created a dedicated package for Shopify for instance.

As you may know, to call an integration flow, you need to have the right credentials and roles to do it.

An integration flow can be called using basic authentication, with a check on the caller's role. This is fine for a pilot, hence we'll use that as security mechanism.

Add an HTTP Sender Adapter with the configuration as depicted below.

Deploy your integration flow so we can test it later on.

To call that integration flow, you will need to create an API Service key that will contain credentials (clientId & clientSecret) for a specific role, such as "ESBMessaging.send".
You may have created an API Key: in that case you can use its credentials. If not, follow the next steps.

The whole process of creating an API key is described in detail here, but basically you need to:

go to your subaccount
create a new instance of SAP Process Integration Runtime ("integration-flow" plan)
create a service key for that instance

The result looks somewhat like this:

Once the key is created, copy clientId and clientSecret: we will need it later to trigger the iflow.

Setting up Postman for testing

I am a big fan of Postman since its very beginning, so I will use that to test the call against my integration flow. But you can also use free tools such as ReqBin.

Before you create the request, we need to get the endpoint URL of the integration flow. It can be found in the Monitor / Integration and APIs / Manage Integration Content screen.

Copy the URL of the endpoint and use it in the client of your choice to create your POST request.

In the Authentication tab, select Basic Authentication and enter your clientId and clientSecret as credentials.
It should look like that.

Setup Shopify Webhook

Let's now define a webhook in Shopify. To do so, login to Shopify and navigate to the Settings (the link is at the bottom left of your screen).

Now select Notifications / Webhooks.

Create a webhook for order creation and insert the URL of your integration flow.

Also, copy the value of the key since we will need it later.

Don't get too excited though: this won't work (test it if you want: ... / Send Test) because the integration flow requires authentication!

A way to enable that, is to use API Management, to inject the credentials there.

Setup API Management

The main reason behind using API Management is to centralize security, traffic management and analytics of APIs - making the management of your IT landscape easier.

This works mainly through the usage of so called API Management API Proxies which sit between the caller and the implementation of the API.

To create an API proxy, navigate to your Integration Suite, Configure / APIs.

Click on Create and fill in the fields as depicted below.
The URL should be the endpoint URL of your iFlow.

Once the API Proxy is created, click on the Key Value Maps tab on the top.

Indeed, in order to safely inject the Cloud Integration credentials, we will use the Key Value Map feature of API Management: you can store values in an encrypted way, available only to the API proxy during runtime (vs. hardcoded in the API proxy itself).

Create 2 encrypted KVMs named Shopify and Cloud Integration.

In the Shopify KVM, create a key named WebHookKey containing the value of the Shopify key you copied before.

Do the same for CloudIntegration, with the clientId and clientSecret values from your Cloud Integration API Service key.

Go back to your previously created API proxy and click on Policies (top right on your screen).

Create the following policies to secure the API Call (at least a bit).

1- KeyValueMapOperations policy: retrieve the value of the Shopify key from the KVM. This policy will set the KVM value in a private variable (not exposed through logs or in debug mode).

<KeyValueMapOperations mapIdentifier="Shopify" async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
 <Get assignTo="private.Shopify.webhookkey">
  <Key>
   <Parameter>WebHookKey</Parameter>
  </Key>
 </Get>
<Scope>environment</Scope>
</KeyValueMapOperations>

2- KeyValueMapOperations policy: same as above, retrieve the value of the Cloud Integration credentials from the KVM.

<KeyValueMapOperations mapIdentifier="CloudIntegration" async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
 <Get assignTo="private.clientId">
  <Key>
   <Parameter>clientId</Parameter>
  </Key>
 </Get>
 <Get assignTo="private.clientSecret">
  <Key>
   <Parameter>clientSecret</Parameter>
  </Key>
 </Get>
<Scope>environment</Scope>
</KeyValueMapOperations>

3- BasicAuthentication policy: creates a base64-encoded Authorization header, ie. basic authentication, for the integration flow, using the previously retrieved clientId and clientSecret from the KVM.

<BasicAuthentication async='true' continueOnError='false' enabled='true' xmlns='http://www.sap.com/apimgmt'>
 <Operation>Encode</Operation>
 <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
 <User ref='private.clientId'></User>
 <Password ref='private.clientSecret'></Password>
 <AssignTo createNew="false">request.header.Authorization</AssignTo>
</BasicAuthentication>

4- Python Script policy: executes a hash check. Indeed, we want to check that the call originated from Shopify and was not altered. This is done through the verification of the HMAC (Hash Message Authentication Code) sent from Shopify in a header, using the key available only to Shopify admins (in the encrypted KVM).

<Script async="false" continueOnError="false" enabled="true" timeLimit="200" xmlns='http://www.sap.com/apimgmt'>
 <ResourceURL>py://HashCheck.py</ResourceURL>
</Script>

Now add a new script on the left-hand side menu and name it just like the one you are referencing in your policy, eg. HashCheck.py.

import hashlib
import hmac
import base64
import random
import string

def make_digest(secret, payload):
hashBytes = hmac.new(secret, msg=payload, digestmod=hashlib.sha256).digest();
base64Hash = base64.b64encode(hashBytes);
return base64Hash;

message = "";
message = flow.getVariable("request.content");

webhookHash = flow.getVariable("request.header.X-Shopify-Hmac-Sha256");
resultHash = make_digest( flow.getVariable("private.Shopify.webhookkey"), str(message) );
flow.setVariable("resultHash",resultHash);

lettersAndDigits = string.ascii_letters + string.digits;
randomKey = ''.join((random.choice(lettersAndDigits) for i in range(44)));

flow.setVariable("randomKey",randomKey);
doubleWebhookHash = make_digest( randomKey, webhookHash );
doubleResultHash = make_digest( randomKey, resultHash );

flow.setVariable("doubleWebhookHash",doubleWebhookHash);
flow.setVariable("doubleResultHash",doubleResultHash);

if (doubleResultHash != doubleWebhookHash):
raise NameError("Invalid Origin! Different HMAC.")

Update, save and deploy the API Proxy.

Now copy the URL of the API Proxy from the overview.

If you test the API Proxy through Postman, you will see that API Management is preventing you to do so since the Hash-Check was unsuccessful. Indeed: both the HMAC-SHA header as well as the payload are missing.

This is why we now test it in situ, using Shopifiy's webhook.

Update Shopify

Go back to your Shopify account and update the WebHook URL with the API proxy URL.

If you perform a new test, you should now see the integration flow being triggered properly:

If you have time, you can also intercept the webhook call from Shopify through API Management Debug, and recreate the call in Postman using the X-Shopify-Hmac-Sha256 header value and the payload. This call will work, but as soon as you play the "man-in-the-middle", ie. as soon as you alter the payload, you will get an error.

Mapping in the integration flow

In order to properly communicate to the backend system, you need to perform a mapping between incoming Shopify message and the expected S/4HANA message structures.

This is done using the message mapping flow step, but very much depends on your own setup. Hence I am not going through the details.

However, note that you will need to create an OpenAPI specification from the Shopify webhook call since it is not provided in the documentation. Also, AFAIK, there is no documentation of the data structure of an order, at least not in a usable YAML or JSON format. Feel free to comment if I have overseen anything!

For the OpenAPI spec, the steps I took were:

Get the payload from the Webhook APICall (Debug of API Management for instance)
Transform the payload into a JSON data structure
https://roger13.github.io/SwagDefGen/

Create an OpenAPI file and inject that data structure in the schema part of the OpenAPI definition
https://editor.swagger.io/

When importing that OpenAPI specification into the message mapping flow step of your integration flow, you will notice that some fields could not properly be translated into a proper structure because of missing values.
I replaced the empty properties with dummy properties, enough for the pilot.

"note_attributes": {
   "type": "array",
   "items": {
      "type": "object",
      "properties": { }
   }
},

"note_attributes": {
   "type": "array",
   "items": {
      "type": "object",
      "properties": {
         "note_attribute_property": {
            "type": "string",
            "description" :"Dummy note attribute property"
         }
      }
   }
},

Conclusion

Using the SAP BTP Integration Suite, we have quite quickly created the communication between a cloud application webhook and an S/4HANA system.

As said before, this is only a pilot and a production-grade setup would need additional features such as traffic management or IP filtering, as well as a mapping, possibly more processing in the integration flow and a better security concept.

Best regards!
Sven

SAP Cloud Integration archiving with "OpenText Core Archive for SAP Solutions"

2024-08-23T11:22:20.605000+02:00

Hi all,

This blog is just to bring to light a standard archiving solution working out of the box for SAP Cloud Integration using the "OpenText Core Archive for SAP Solutions".

In one hand If you check carefully the documentation of such product you will notice that there is a standard "CMIS interface" to "Store & Retrieve any content", in the other hand SAP Cloud Integration uses "CMIS interface" out of the box for archiving, so why not put them together? 😉

In a nutshell the following steps need to be followed to have a successful integration:

OpenText – Core Archive - Administration ( http://<host>:<port>/archive/ba/index.jsp )
-Creation of Retention Policy ( Optional )
-Creation of Collection with CMIS Client: You will get the CMIS Browser Binding & RepositoryId - required for the SAP BTP Destination

CMIS Workbench ( in your local machine )
-Import custom CMIS type into OpenText Core Archive: It would be nice than SAP provided this definition, but you can extract it from the traces of Cloud Connector or OpenText Core Archive ( SAP Cloud Integration check if the CMIS type exist via APIs, in case that it does not exist it will try to create on the fly, but this will not work due to OpenText Core Archive, so it must be created manually ).
-Export custom CMIS type from OpenText Core Archive: You will extract the ID for the CMIS type ( OpenText create randoms IDs internally, it is not keeping the IDs provided for the import file ) - required for the SAP BTP Destination ( https://help.sap.com/docs/cloud-integration/sap-cloud-integration/configuring-destination )

SAP Cloud Connector Set-Up
-Expose the OpenText Core Archive & CMIS resources: Add the OpenText Core archive system and expose everything under "/as_cmis"

SAP – BTP – Service Instance & Service Key
-Create Destination: Just use the CMIS Browser Binding & RepositoryId, Cloud Connector Location ID, and user with write permissions, and the most important part is the additional property "CustomAttributeAndTypeNamesMapping" ( https://help.sap.com/docs/cloud-integration/sap-cloud-integration/configuring-destination )

SAP Cloud Integration enable archiving
-Enable archiving: enable the archiving functionality ( https://help.sap.com/docs/cloud-integration/sap-cloud-integration/enable-archiving-in-cloud-foundry-environment )

OpenText – Core Archive - Access ( http://<host>:<port>/archive/access/index.jsp )
-Navigate the collection: Enjoy an out of the box solution to navigate & search archived files by all the attributes enabled for it.

Not forget, be curious! 😉

Max.

🚀 Exciting Course Alert: Modernizing Integration with SAP Integration Suite 🚀

2024-08-23T16:23:05.162000+02:00

Exciting news for those looking to enhance their integration expertise! Starting August 28, 2024, SAP is offering a free learning course titled "Modernizing Integration with SAP Integration Suite." This course provides a thorough introduction to SAP Integration Suite and its transformative capabilities.

Course Overview

The course covers essential aspects of SAP Integration Suite, including:

Key Capabilities: Learn about the core features of SAP Integration Suite and how they streamline integration processes.
Enterprise-Wide Integration Strategy: Understand the critical role of a well-defined integration strategy in today’s digital landscape.
AI and iPaaS Integration: Explore how artificial intelligence and SAP’s integration platform-as-a-service (iPaaS) can modernize and innovate your enterprise.

Why Enroll?

Accelerate Cloud Migration: Implement a hybrid integration approach to speed up your transition to the cloud.
Enhance Business Agility: Utilize the diverse tools and prepackaged content of SAP Integration Suite to boost business responsiveness.
Modernize Your Enterprise: Leverage SAP’s iPaaS to transform your organization into an intelligent, modern enterprise.

Join the Discussion

The course includes access to an online discussion forum from August 28 to September 30, 2024. Engage with SAP experts, ask questions, and collaborate with fellow learners to enrich your understanding.

Register Now

Don’t miss this opportunity to advance your skills with SAP. Sign up today and start your journey to mastering SAP Integration Suite!

CPILint version 1.0.5 is here

2024-08-29T01:40:40.485000+02:00

The very first version of CPILint was released on August 31st, 2019. With the 5th anniversary just around the corner, I am excited to announce that version 1.0.5 is complete and ready for you to install.

If you already run version 1.0.4, you will automatically be notified that there is a new version available. You can also go directly to GitHub to download it.

In this blog post, I will give you an overview of what’s in version 1.0.5. If you are new to CPILint, let me start by giving you the elevator pitch:

CPILint is an open-source tool that automates your SAP Cloud Integration governance. It ships with a range of built-in rules covering topics like developer guidelines, naming conventions and security. You choose the rules you want to put in place, and CPILint does the heavy lifting of checking your integration flows for compliance.

Now, let’s take a look at all the good stuff in the new release!

OAuth 2.0 support

CPILint communicates with your SAP Cloud Integration tenant via the official OData API. This requires authorization, of course, and so far we’ve done this by providing a username and password.

In version 1.0.5, however, you can authorize simply by creating a service key for CPILint in the SAP BTP Cockpit and downloading it to your local machine. You use the new -key command line option to point to that key. CPILint then uses your key to authorize its API calls using the OAuth 2.0 client credentials flow.

This has several benefits for you. First off, you no longer need to provide a username and password. Second, since the tenant hostname is already in the key, you no longer need to provide that either. Third, running CPILint with minimal permissions is now very easy to get right. Finally, the OAuth 2.0 client credentials flow is more secure than basic authentication.

With the new OAuth 2.0 support, checking your entire tenant for compliance is now as simple as:

cpilint -key my-key.json -rules my-rules.xml

Short and sweet!

Rules file import

Up until now, every single rule you wanted to check had to be stored in a single rules file. With CPILint version 1.0.5, we get a lot more flexibility. The new version introduces the ability to import a rules file into another rules file. You do this using the new <import> element.

If you have, for instance, a separate rules file for a specific project package but also want to reuse naming conventions that apply to the entire tenant, you can now simply import those naming conventions into the project’s rules file like this:

<cpilint>
    <imports>
        <import src="/path/to/naming-conventions.xml"/>
    </imports>
    <rules>
        <!-- Your project-specific rules would go here. -->
    </rules>
</cpilint>

This feature opens up entirely new ways to shape and mold your rules files and I’m excited to see how the community will put it to use! To learn more about rules file imports, visit this wiki page.

New rule: UserRoles

UserRoles is a new rule in CPILint 1.0.5 that lets you specify which user roles should and should not be used in sender channels that support user role authorization (meaning AS2, AS4, HTTPS, IDoc, SOAP, XI, and OData). If you, for instance, do not allow the use of the default user role (ESBMessaging.send), you would add this rule:

<disallowed-user-roles>
    <disallow>ESBMessaging.send</disallow>
</disallowed-user-roles>

You can also use the UserRoles rule to require, for instance, that only certain custom user roles be used.

Other news

1.0.5 adds 30 supported names to the NamingConventions rule. Check out this page in the CPILint wiki for the full list of supported names.

There’s a new command line option called -skipvercheck that skips the automatic check for a new version. If you run CPILint in a non-interactive way, like for instance in a CI/CD pipeline or other automation context, you might want to do this to save a little time and bandwidth.

The DuplicateResourcesNotAllowed rule now supports JSON resources.

There is now an FAQ page in the project wiki.

Last but definitely not least: The CPILint ASCII art is now 3D. Yes, I saved the best for last!

Over to you

That’s it for the CPILint 1.0.5 overview. Take the new release for a spin and please share your feedback with me in the comments below.