Cloud Integration allows us to make changes over the messages, like mappings, or converting from one structure to another. Cloud Integration is not only powerful for data manipulation, but also offers strong monitoring features. In addition to Debug or Trace modes like any development IDE, it also allows us to monitor the necessary information without debugging.

For each service we can set Log Level to 5 different modes.

Default log configuration is set as Info. Which allows us to see status of every process, like completed, abandoned, canceled, failed, etc. This mode doesn’t allow us to see the message body, message headers, basically what is passing through over CPI. It is important to protect data for security reasons and to reduce memory consumption.

But if the process fails, how can we find out the issue?
Trace mode is useful when the same message can be received again. Before receiving messages, this mode should be activated. In trace mode, both the message body and headers can be viewed at each step.

The process that gets an error is displayed. In this mode, it is much easier and faster to identify the step where the error occurs.

However, CI allows us to stay in trace mode for only 10 minutes, then it returns automatically to the previous mode (info, error, or none). Additionally, the message can no longer be accessed after 1 hour. During development, this mode is often used. However, in production, after the process fails, we cannot re-trigger the same process. It is also not recommended to reveal the full message in production due to security reasons.

In that case, how can we indicate which message gets an error without exposing the entire message? Here’s what SAP offers:

There are some pre-built properties for monitoring and filtering messages. This feature is very helpful for understanding specific messages’ status and filtering the messages in monitoring screen. We can customize those Properties according to needs. In this example, Application Message ID is set from Order Id, and the type of Order is set as Application Message Type. If this order gets an error, we can directly point out the order number without revealing the whole message.

Bestellnummer festgelegt, und der Bestelltyp wird als „Application Message Type“ bestimmt. Wenn diese Bestellung einen Fehler enthält, können wir die Bestellnummer direkt herausfinden, ohne die gesamte Nachricht offenzulegen.

If those pre-build properties are not enough, or just need to add more customized properties, we can also add custom monitoring headers. These custom headers are not considered as actual headers. They are not sent to the receiver system. They are used only for monitoring purposes as internal.

We can also filter the messages according to monitoring properties and custom headers. For example, we have 7 messages in Completed status with the Message Type: Initial Order

But we have only 1 message with the order number 1000000.

By default, we cannot view the content of a message at any point during the process. However, in some cases, we may need to see the message body, especially when it’s in a failed status. To do this, we can create an attachment for monitoring purposes. Attachments can be in any text format, and they are customizable, allowing us to add information that helps identify the error. Additionally, attachments can be set up to be included only in error cases.

Most common usage cases:
– Seeing the whole body at the important points. – Like before mapping, after mapping
– In error case, the whole message body at the error point.

By default, Cloud Integration interface does not show any messages or headers to users. This is important for both security reasons and memory management.

However, in some cases, the failed message needs to be detected without using trace or debug mode, especially in a production environment. To achieve this, in info mode, necessary fields can be set as custom properties and attachments to identify which message has failed.

Cloud Integration stores logs maximum for 1 month. This 1-month period is intended for working with errors, detecting issues, and solving problems.

The post Monitoring in SAP Cloud Integration appeared first on Rhein-Ruhr-Informatik.

SAP BTP allows the deployment of multiple services and applications, each with its own role collections. These services are often deployed across different subaccounts. It's possible to manage users and roles separately in each subaccount.

However, it is also possible to centralize user and role management by using a single identity service by establishing trust between the identity service and BTP subaccounts.

This post will guide you through setting up role collection mappings between BTP and Identity Authentication Service (IAS). This allows you to manage role collections for multiple subaccounts from a single identity provider.

Prerequisites

If you have an identity provider, you can configure it as a custom provider for a BTP subaccount. It can be used as the source for users and role collections.
There are some prerequisites for setting up role collection mappings:

• You must have the Subaccount Administrator role in the subaccount that will be linked (trusted) with SAP Cloud Identity Services.
• The SAP Cloud Identity Services tenant can be subscribed to in a different subaccount, but it must be part of the same global account and in the same region.

You can follow the steps in this SAP Help document to configure the trust between your subaccount and the SAP IAS tenant:

👉 You can follow the steps in this SAP Help document to configure the trust between your subaccount and the SAP IAS tenant:

NOTE: To be able to use the role collection mapping, you must log in to the application with a user that is defined in the identity provider. - Not with a BTP user.

Configurations

1. BTP Role Collections

Before creating a role collection mapping, make sure that you have the necessary role to access “Role Collections” in your subaccount.

Navigate to:

<Ihr Subaccount>          →    Security     →   Role Collections 

You can use default role collections that are defined for the standard BTP applications.

Alternatively, you can create a new custom role collection by clicking on the Create button in the top right corner.

SAP BTP Role Collections

In this example, a new custom role collection called “My_Custom_Role” is created.

• SAP Cloud Identity Services

Before starting to configure role collection mapping, we must ensure that we send necessary attributes to the application. In the SAP Cloud Identity Service, navigate to

 Application & Resources   →  <Ihr Anwendung>  →  Single Sign-On  →  Assertion Attributes

Application Page on SAP Cloud Identity Services

In the assertion attributes, you must have a Groups attribute. This is what we will send to the application as a BTP role.

Assertion Attributes of an Application on SAP Cloud Identity Services

Then we should create a group for a BTP role that we will be mapping. Navigate to
                        Users & Authorizations   →  Groups

Create a new group, if you have already one, add members who will have this BTP role.

Groups and its Users on SAP Cloud Identity Services

• BTP Role Collection Mapping

Now we are ready to make role collection mapping. Go to your BTP subaccount and navigate to
                        <Ihr Subaccount>   →   Security   →   Trust Configuration,

and click on the custom identity provider that you have established in the beginning.

SAP BTP Trust Configurations

Click on the New Role Collection Mapping and choose your BTP role collection (1). You can also choose your BTP custom role collection.

For “Attribute”, you should write what you defined in IAS as a Groups attribute (2). In this case, we can leave it as “Groups”.

In the “Value” section, you should write your IAS group’s name which corresponds to your BTP role collection (3).

Then save it.

SAP BTP Role Collection Mapping

You can see your mapping from Role Collections.

SAP BTP Role Collections Mapped with IAS Groups

Conclusion:

• You can manage this role collection on SAP Identity Authentication Service with managing the corresponding group’s members.
• In the BTP subaccount, you cannot see the user's role assigned by IAS. These roles are assigned to users when they are authorized to your application via SAP IAS.

Note:

Please be aware that your IAS user must be created in your SAP BTP subaccount as well. You can check more about to create user on BTP from here:

👉 Managing SAP BTP Users

Hope this blog will help you to manage your BTP roles from your identity provider!

Feyza Sahin

The post Verwaltung von BTP Role Collections über den SAP Cloud Identity Service appeared first on Rhein-Ruhr-Informatik.