In my previous blog post, we saw how one can Add Custom Context Attributes for SAP Released Event Types. From release 2308, we can go one step further and create a new custom RAP event from an SAP standard event. This event type is called Derived Event and is immensely popular among our customers.
For those who are new in the topic, please follow the blog series introduced in SAP Community ABAP Connectivity page under Enterprise Event Enablement feature content to learn how to produce and consume RAP business events and get more details in regard to it.
Under SAP Business Accelerator Hub, you can find all available Event Objects. However, only those events developed as an extendable cloud object can be maintained. To find them out, in SAP Business Accelerator Hub - On Stack Extensibility in Business Object Interface area, look your topic of interest, let us say ‘Sales Order’
Here, in General Information Section, you will find the name of the Extensible Interface BO:
For developer extensibility, you need to extend the underlying RAP BO R_SalesOrderTP to trigger a custom event when the SAP-defined event is raised.
The new custom events that are added there, will be published and thus consumable through the published interface. This is the same approach like when adding additional determinations or validations to an extensible RAP business object.
The underlying RAP BO will have typically the same name only starting with an “R_” instead of “I_” as the interface listed in the Business Accelerator Hub. So “R_SalesOrderTP” instead of “I_SalesOrderTP”.
Unfortunately the SAP Business Accelerator Hub does only show the interface I_SalesOrderTP because it focuses on Key User Extensibility so far. As mentioned above, we however need to extend the underlying R_SalesOrderTP object. To find the extensible R_-object we describe in the following several options:
To start with, create the Released Objects view on the repository of your system in your ADT Project as it is explained in my previous blog post.
In Project Explorer, extend your S/4 HANA cloud system, then under ‘Released Objects, EXTENDED_IN_CLOUD_DEVELOPMENT’ section, choose ‘Core Data Services, Behavior Definitions’, open the underlying RAP BO R_SalesOrderTP of the interface you found in the previous section in which the events are defined.
As you can see, this RAP BO is extensible and contains three kinds of events. Besides, the event referenced by the derived event needs to be exposed in the C0 and C1 released RAP BO interface, also the CDS view entity which serves as the data source for the payload of the derived event needs to be C1 released. More can be found SAP Help Portal, on Derived Business Events.
To extend this RAP BO, on the left-hand side, right click on the name R_SalesOrderTP and choose ‘New Behavior Extension’ option. Choose your package and give a name and description for this behavior extension.
You have to enter the name of the interface I_SALESORDERTP in the field BO Interface. The name of the Behavior definition R_SalesOrderTP will be added automatically.
Click on ‘Next’, choose your transport and click on ‘Finish’. Your behaviour extension is created. Since our extension concerns a minimal change in the payload, we do not need to do much coding like adding a class as such. So, simply replace the generated code with the following lines:
extension using interface i_salesordertp;
extend behavior for salesorder
{
managed event zzSGBEvntCreated on created parameter ZR_CUSTOMSALESORDER;
}
Our aim is to extend the SAP event ‘Created’. The keyword for defining the Derived Event is ‘managed’ as a Derived Event is a managed event. Then, we define this new event by giving a name for it. This event name must be started with either 'zz' or 'yy'. Then you need to provide a view entity as a parameter in which the Derived Event will be defined and contains the payload you want. It would be better to define this CDS view in advance, but you can add it here as well.
Technically speaking, the Derived Event is a new event, the so called ‘old’ standard event stays as it was defined originally. In another word, although we are speaking of an extension, with Derived Event we are just cloning that original event in a sense that we DO NOT change the payload of the original one, all changes are done in the new Derived Event payload. In this case, whenever an SAP event is generated, a Derived Event will be triggered automatically.
It is essential to consider that the CDS view which defines the Derived Event payload must have the same key fields as the root view in the BDEF. Besides, there should not be any associations defined in this view entity. Here, we select the fields from the I-view. However, you can technically use any view which has the same keys.
As an example, we would like to have the following fields in the payload whenever the total net amount is more than a specific number. So, we define the view as
define view entity ZR_CUSTOMSALESORDER
as select from I_SalesOrder
{
key SalesOrder,
TransactionCurrency,
@Semantics.amount.currencyCode:TransactionCurrency'
TotalNetAmount
} where TotalNetAmount > 9999
Using where phrase, you can set a condition acting like a filter. For example, this event will be triggered whenever the Total Net Amount is equal or more than 10000. In this case, the query on the CDS view is executed and if no data is returned due to the WHERE-condition, no event is triggered. Note that in case of a deletion, there is no record left in the table and no derived event can be raised. Hence, be careful when creating derived events on deletions.
Until now, we create a new event which works like any other standard events. This means, to use this event we need to create the event binding and then configure the channel binding.
Now we design our custom event, and we like to expose it to the consumer world. Following the standard procedure, the next step is mapping this event to the external event infrastructure by creating an event binding. This concept is already explained in Creating RAP Business Events blog post. The event binding belongs to the design time, here you define how should your event type look like i.e. with which topic name you want to expose it. Add the event binding exactly like it explains for a RAP event. After filling out the ‘General Information’ section, click on ‘Add’ option and provide with the entity name and the event name. Here, the entity name is the name of the extensible interface, and the entity event name is the name you already choose for your Derived Event.
Now save and activate the event binding. As we are finishing with the design time, we need to continue with the configuration time to be able to consume this event.
As a next step and similar to an standard event configuration, we need to create a channel and configure the channel binding. In the consumer system, create a communication arrangement as it explains in SAP help page on Creating Communication Arrangement. It is also discussed in creating RAP Business Events blog post.
By creating the communication arrangement, a channel will be created respectively. You can also use any existing active channel if you want. Now, we need to add the event topic to the outbound channel. This is done by the outbound configuration. After selecting your channel in ‘Maintain Event Channel Binding’ application, click on ‘create’ and find the topic which is generated during the event binding creation.
Click on ‘Create’, the topic will be added to the outbound topic bindings of the channel:
As said, whenever an standard event is triggered, a Derived Event will also be triggered accordingly. In our case, this means after creating a new sales order.
Then, open ‘Enterprise Event Enablement-Event Monitor’ application, choose your channel and check the event payload, as it can be seen, the fields we were interested in, are added to the payload:
In this blog post I explained how one can create a RAP custom event based on an SAP standard event type. This new event is raised with the corresponding SAP released event. We also see that by means of a ‘Where’ condition, we can set a limitation for triggered custom events, i.e. if the SELECT does not return any data, the derived event will not be triggered/send.
In the next post, I would like to show you how you can do source filtering of events and defining filterable properties. I will also introduce dynamic topics and explain how one can use them for routing and filtering in SAP Integration Suite, Advanced Event Mesh (AEM). So, please stay connected!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
26 | |
13 | |
11 | |
10 | |
8 | |
7 | |
7 | |
7 | |
5 | |
5 |