Updated on June 09 2021:

As of SAP Business ByDesign version 2105, Event Notification is introduced as a standard feature, which creates business object change notifications and get notified to a specific endpoint via these business events. Please check this online help for details.

As a rule of thumb about choosing the standard Event Notification or byd-event-bridge as a custom PDI solution. In general, it is recommended to make use of this standard event notification over the byd-event-bridge PoC introduced below.

• If the target endpoint of event consumption(namely event subscriber) requires authentication as no authentication,basic authentication and OAuth 2.0, please go with the standard Event Notification in SAP Business ByDesign. For example, customer invoice event to be consumed by SAP Integration Suite with basic authentication or SAP Event Mesh(formerly as SAP Enterprise Messaging) with OAuth 2.0, or your custom endpoint with no authentication etc.
• If the target endpoint event consumption(namely event subscriber) requires authentication methods like Shared Access Signature(SAS) such as Azure Queue Bus, and
  AWS Signature V4 as AWS Simple Queue Service, then you may look into the byd-event-bridge below.

This blog post is part of the blog post series about the event-driven architecture for SAP Business ByDesign by my colleague Maria Trinidad MARTINEZ GEA.  In this blog post, I will introduce an event bridge prototype(ByDEventBridge) for SAP Business ByDesign implemented with SAP Cloud Application Studio via an Internal Event Pushing approach.

As a legal disclaimer, this prototype is not an official SAP product or feature, neither an endorsement nor any implication of SAP Product roadmap, hence no official SAP support on it. The source code of the prototype is published on github under an Apache 2.0 license with an AS-IS manner. It is on your own obligation and risk in case of adoption.

Overview of ByDEventBridge

The prototype ByDEventBridge captures and persists the Creation/Update/Deletion operations(namely Business Object Event) of system and custom business objects on SAP Business ByDesign, and pushes the event messages in real-time or periodically to external messaging brokers(queues/topics) such as SAP Cloud Platform Enterprise Messaging, SAP Cloud Platform Integration, Azure Service Bus, AWS SQS/SNS etc.

Partner external applications or serverless functions namely event subscriber can be triggered by the event upon subscription. The use cases could be:

• eInvoicing exchange among buyer and supplier system per B2B scenario for invoice automation.
• Event-driven production automation. For instance, releasing a production order in ByD triggers the production operation of manufacturing machine in factory in real-time without human involvement.
• Event-driven communication and collaboration automation among Things, People and Business. For example, getting instantly notified with a business event about who have done what at when through your favorite messaging app like WhatsApp/Messenger etc, or a seamless integration with collaboration platform like Slack/MicroSoft Teams etc, or business event feeds listed in ByD overview page.
• etc…

Simply put, this prototype enables a state-of-art event publication and subscription mechanism for SAP Business ByDesign by plugging into modern cloud messaging services for side-by-side solution/extension development via an event-driven and loosely-coupled approach with great flexibility and scalability.

A demo video clip:

Technical Details about ByDEventBridge

Architecture and design

High-level architecture of the ByDEventBridge prototype

The logical components diagram of ByDEventBridge prototype

The class diagram of ByDEventBridge prototype

The architecture diagram  above illustrates its major components as below.

ByDEventBridge – Solution within SAP Cloud Application Studio

The ByDEventBridge is an In-App extension built with SAP Cloud Application Studio, which is mainly in charge of the life cycle of a business object event as below.

• Event Generation
  The event about creation/updating/deletion operation of a business object instance is captured on BeforeSave or OnDelete of the desired node in the source business object, which could be both a Business Object Extension of system BO or Customer Business Object with a reusable code snippet.
• Event Persistence
  The business object event is persisted in a custom business object named BusinessObjectEvent, including the information of Event ID, Object Type, Object ID, Object UUID, Event Type, Source Tenant Host, Source Node Name, Source Node ID, Event Status, Real-time Publication, and Administration Data about the Event such as when it is created by whom, in addition, an business object is associated with an instance of ObjectEventConfig on Object Type, and a list of Publications about how the event is to be published.
  
• Event Configuration
  • EventPublicationChannel:
    An event publication channel holds the information of a tangible channel where the ByD event message is sent to, such as Channel ID, Channel Name, Channel Type, how to authenticate channel access and how to publish the event to the channel.Supported publication channel type as:
    • SAP Enterprise Messaging through OAuth 2.0
    • SAP Cloud Platform Integration through Basic Authentication
    • Azure Service Bus Queue through OAuth 2.0 and Shared Access Signature
    • AWS Simple Queue Service(SQS) through a custom REST API in AWS API Gateway and an additional Lambda Function sending message to AWS SQS with AWS SDK.
  • 
  • ObjectEventConfig:
    An event configuration on business object level, such as Is it marked as Real-time Publication, and a list of publication by channel, associating to an instance of EventPublicationChannel on ChannelID, which are populated to its BusinessObjectEvent instance.
    
• Event Publication
  
  The event publication supports
  • Real-time Publication on the event generation
  • Periodical Mass Publication via background job
• Event Deletion
  The event could be deleted
  • By manual through UI
  • Periodical Mass Deletion via background job

External Messaging Brokers – Cloud Messaging Services

A message broker translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. In our case, the sender is SAP Business ByDesign, and the message is communicated as JSON format through https protocol.

{
  "EventID": "11",
  "SourceTenantHost": "https://myxxxxx.sapbydesign.com",
  "EventType": "02",
  "ObjectType": "004",
  "ObjectID": "1INV-13-2020",
  "ObjectUUID": "00163E71D7E21EDABFCDC7A6D20AB21A",
  "SourceNodeName": "Root",
  "SourceNodeID": "00163E71D7E21EDABFCDC7A6D20AB21A",
  "CreationDate": "2020-09-24T14:07:21Z",
  "PublicationDate": "2020-09-29T13:46:46Z"
}

Here, we are more interested on Cloud-based Messaging Service with its easy consumption, flexibility and scalability. The message brokers supported in this prototype list below.

• SAP Enterprise Messaging
• SAP Cloud Platform Integration
• Azure Service Bus
• AWS Simple Queue Service(SQS) (In the prototype, AWS SQS is used for sample, however it also applies to AWS SNS with the same sample code.)

Precisely, it is more about how to authenticate and access the external message broker through http(s) in ABSL rather than message broker types. The following authentication methods are implemented in the prototype to send the ByD event message to the broker.

• No Authentication
• Basic Authentication
• OAuth 2.0
• Shared Access Signature
• API Key

As a result, in theory, any http service with the authentication method could above be sent to by ByDEventBridge.

Event Subscriber

The event subscriber here is a partner application subscribing to the queue or topics in the message broker, and getting triggered on certain event from certain source, and react with custom business logic, technically, which could be a completed http service application or Function-as-a-Service(FaaS) such as Azure Function or AWS Lambda Function. In addition, it is flexible to choose a programing model to implement the event subscriber at your best suit. The event subscriber with FaaS could be easily scaled horizontally or vertically.

Since the event message only includes the minimum information about event such as the object, event type, source tenant, source node etc instead of a completed object instance, hence it is the event subscriber’s responsibility to retrieve the required information of the object instance for further processing, either through OData query(recommended) with desired field selections or Web Service call to the source SAP ByD tenant.

Here you have an sample app(eInvoicing) by my colleague Thiago Mendes on SAP Cloud Platform, Cloud Foundry as event subscriber, generating the electronic invoices based on the event of customer invoice from SAP Business ByDesign, which is published to SAP Cloud Platform Enterprise Messaging.

Another sample about ByD Event Subscriber is an https-triggered integration flow of SAP Cloud Platform Integration by my colleague Maria Trinidad MARTINEZ GEA.

Adoption practices guide

First of most, before any productive adoption, it is certainly worth trying it out, and evaluating the solution against the use case from both technical and business perspectives.

Since the prototype ByDEventBridge is a customer-specific solution built with SAP Cloud Application on our internal tenant, therefore it is not possible to download the source code, then directly import and deploy to another tenant. And the published source code  only includes BODL and ABSL files, the wizard-based artifacts are exclusive due to the fact of their strict dependence with tooling and tenant, such as UI Screen, Query, Mass Data Run, External Service Integration, Communication Scenario and Communication Arrangement etc… which require to be created or configured with your own SAP Cloud Application on your own target ByD tenant. Please refer to the source code and manual about how to create your own ByDEventBridge.

Frequently Asked Questions:

1. Adopting ByDEventBridge as a Customer Specific Solution or Solution Template or Multiple Customer Solution?
   Answer: It is recommended to create a solution template including all reusable artifacts, such as BODL file, ABSL file and Reuse Library etc which are shared in this github, then you create customer specific solution by importing the solution template. In the long run, if you think it as a good solution which you would like to resell to multiple customers, then you can request approval to create a multi customer solution, and importing the solution template.
2. What are the best practice for event operation?
   Answer: As rules of thumb
   • Only generate the event on the target node of the desired object. Filter the undesired event message as early as possible.
   • Be very careful to generate the event for the very low-level foundation object such as BusinessPartner and Material etc. As BusinessPartner object is depended by Employee, Account, Supplier etc.
   • If it doesn’t require real-time, periodical Mass Event Publication is recommended to minimize the impact on your ByD tenant.
   • To reduce the size of events, the completed or obsolete events should be periodically deleted by Mass Event Deletion(Mass Data Run Object).
3. What cloud-based messaging service to use?
   Answer: Although, the sample prototype is cloud-messaging-service-agnostic, supporting SAP Enterprise Messaging, SAP Cloud Platform Integration, Azure Service Bus and AWS SQS.In reality, most likely one type of cloud message service is enough.It is up to your company’s strategy and client’s preference to pick. If the client opt-in one vendor strategy, then SAP Enterprise Messaging or SAP Cloud Platform Integration is the right choice since they have already been a SAP customer for SAP Business ByDesign. for details, you may refer to the blog posts SCP Enterprise Messaging for the SMBs by my colleague Thiago Mendes, and SAP Cloud Platform Integration for SAP Business ByDesign webinar  by Maria Trinidad MARTINEZ GEA .
4. Can I send the event directly to my external app without a cloud-based message service?

   Answer: Yes. The ByDEventBridge itself implements the event pub/sub mechanism. Publishing the event message to ANY http service with the following authentication by defining a publication channel with the target http access endpoint.

   • No Authentication
   • Basic Authentication
   • OAuth 2.0

   Therefore, you can the event message published to an external partner app directly for processing, which can handle an http request without a cloud-based message service.
5. When do you need event? What granularity of messaging queue or topic and partner solution as event subscriber?
   Answer: The granularity of messaging queue or topic could be per partner solution/object type/source tenant or any combination, giving the flexibility of partner solution development and operation for addressing the variety of business and security etc requirements. For instance
   • Case#1: Your company(SAP Partner) would like to develop and operate an eInvoicing solution as SaaS for multiple ByD customers, it is recommended to have one queue per client for the invoice object for the separation, and also due to the fact most cloud messaging service are charged by the number of messages, not by the number of queue.  For the eInvoicing app(event subscriber) which could be multi-tenant sharing among tenant, and you may need to design a mechanism when and how-to scale. If the eInvoicing app is implemented with serverless function, then it could be dynamically scaled up or down to accommodate the client requests with ease of mind. The pricing of your SaaS now could be easily calculated by the number of messages, and the process time of messages.
   • Case#2: Your ByD client A requests an integration of warehouse activities in ByD with their in-house Warehouse Management System. Of course, the requirement could be implemented with Cloud Application Studio, OData/Web Service of SAP ByD or SAP Cloud Platform Integration etc, which it doesn’t need event and additional messaging service. However, with increase of the complexity of integration and the number of systems to be integrated, an event-driven architecture becomes appropriate. In this case, you may request the client to purchase an appropriate cloud messaging service, and you will help to bridge the event in SAP ByD and integration scenario development.

Summary

As a conclusion, side-by-side and keep-the-core-clean are not just marketing slogans, but a reasonable and practical approach to build your own extension and solution outside SAP Business ByDesign in the cloud era. With an internal-event-pushing ByDEventBridge, SAP Business ByDesign can become event-driven, and can be connected with the sorts of Cloud Messaging Services for side-by-side extension and solution development with the following benefits:

• Simplicity: Easy setup and consumption of queue and topics in Cloud Messaging Service. Focus on your partner solution as event subscriber without worrying how the event is generated and published securely and reliably.
• Flexibility:  Various choices of Cloud Platform vendors,  programing models,  server or server-less architecture,  pay-as-you-go or other commercial contracts.
• Scalability: Built-in scalability from Cloud Platform vendor about the messaging service and event subscriber with FaaS etc.

If you have any feedback or question on this regard, please feel free to leave a comment below. For a technical issue, an issue on github would be appropriate. You are welcome to contribute to the github project about ByDEventBridge.