Understanding the BRH Design Principles for Integrators

Understanding the BRH Design Principles for Integrators

Objective

After completing this lesson, you will be able to design the integration strategy

BRH Design Principles for Integrators

SAP Batch Release Hub for Life Sciences is a Cloud Software as a Service application, built on top of the SAP Business Technology Platform, that enables unprecedented speed and gradually introduces automation approaches for the release of new batches of products. This process is particularly complex for software solutions that deal with "pharma" products that (should / could ) impact the health of animals and human beings, since to lower the risks of adverse impact and guarantee highest positive effects, it requires information from a variety of different systems to be collected and being reasoned upon (automatically or manually).

Note

For more information we recommend to participate in our Learning Journey:Discover SAP Business Technology Platform | SAP Learning.

In the developer's guide you will find all the details of the software architecture, however for sake of faster access hereafter is the diagram directly included from that documentation.

One can integrate with SAP BRH via asynchronous communication (events via event mesh), as an alternative to the OData APIs which differs just in terms of communication channel and not of semantic content", however hereafter we are going to focus on the OData Api.

In fact, a key feature of this application is its integrability through well specified and maintained Application Programming Interfaces using the open standard OData version 4 and using EVENT API

Tutorials on the topic of OData, and specifically its use on the SAP Business Technology Platform are already available and therefore it is not the purpose of this tutorial to duplicate that knowledge.

Here instead we would like to demonstrate how to:

1. provision of data into SAP Batch Release Hub for Life Sciences in an automatic way 
2. query SAP Batch Release Hub for Life Sciences without using the User Interface, but instead in a programmatic way (for example using the SAP Batch Release Hub for Life Sciences Application Programming Interfaces).

GENERAL DEFINITION

General Definition

Data Warehousing applications address the need of consolidating data from different sources and providing business value. In Data Warehousing, the concept of a "Staging area" has emerged as good practice. Its main value is for facilitating data cleansing and consolidation for operational data from numerous data sources, as well as to facilitate auditing. In an ERP, a "Staging area" is used for interim storage of goods in the warehouse. They are located in close proximity to the doors assigned to them.

Using a "Staging" area implies the need of some additional action before it can be "consumed" by the application, therefore it can be seen as "burden" and in cases where no "cleansing" or "editing" of the data is foreseen, it might not be needed. In other words, a staging area is an intermediate storage area used for data processing ,and their main motivation is to increase the efficiency of the data integration process, ensuring data integrity and support data quality operations.

Specific for SAP BRH

SAP Batch Release Hub for Life Sciences allow customers to send their data to the "Active" area or to the "Staging" area, according to their specific needs.

If the customer sends the data to the "Staging" area first, they must also "activate" that data.

While in the "Staging" area, the customer can delete the data, however as soon as the data is "activated" it cannot be deleted or modified anymore.

Only the data that is in the "Active" stage is then processed by the rule engine and be usable for the Batch Release Decision process.

General Definition

Data integration means that data has to be communicated between computer systems. There are two major types of communication modes: Asynchronous and Synchronous.

Asynchronous communication mode

A request message is sent out but no response is expected. One can compare this communication as sending an email: you know when you send it, however you do not know if and when a person has read the mail. In case of sending many mails to that person, they will be able to read the emails in the preferred order and not necessarily in the same order you sent them.

Asynchronous operations only have one message type: the request.

The example shows an asynchronous message exchange where a request message is sent from the service consumer to the service provider, or a person sending an email with a computer.

Specific for SAP BRH

Batch Release Hub for Life Sciences supports both Asynchronous (EVENTS) and Synchronous (ODATA4) communication modes.

The detailed documentation of Asynchronous is accessible at: Asynchronous (Events)

Synchronous communication mode

A response is expected for each call or request message that is sent out. A real world example of synchronous communication mode is an interactive meeting with more participants, where each participant gives immediately their opinion on the matter presented; another example is two persons talking to each other using an analogue phone or in person. The speech that is spoken between the participants in the call is received in the same order that it was sent, otherwise the phrases will not be understood.

Synchronous operations require three message types:

• the request
• a response
• a fault message type

A fault message represents the message that is expected in case an error occurs.

The figure above shows a synchronous message exchange including a request and response message being defined for the service interface operation, and a group of people interacting in a meeting.

Specific for SAP BRH

Batch Release Hub for Life Sciences supports both Asynchronous (EVENTS) and Synchronous (ODATA4) communication modes.

The detailed documentation of Synchronous communication mode is accessible at: Synchronous (Odata4)

In the above figure one can see that in SAP BRH, if using the Asynchronous approach, the data is directly written in the Stage environment and then automatically activated and pushed in the Active area.

Instead, if using the Synchronous approach, one must activate it manually or through a separate API call, or using the -x-sapbrh-autoactivate header in the POST command.

SAP Batch Release Hub for Life Sciences (SAP BRH) is like a funnel: decisions about the release of a batch is taken when all data is available. Therefore, SAP BRH gets filled with data and then takes efficient decisions.

The incoming data is provided through so-called "Inbound" methods, while the decision is called "Outbound" .

In this Lesson we will focus on understanding how to provide data in SAP BRH from non-S4 systems.

In fact, SAP S/4HANA SAP BRH has a facilitated integration path, given that SAP S/4HANA and SAP BRH are both made by the same vendor: SAP.

However, the SAP S/4HANA integration also uses at the core the same approach that is described in this lesson, however it simplifies its use for some of the entities exchanged.

SAP BRH is a highly integrated system, designed to greatly reduce the amount of time required by the Authorized Person in order to take a Batch Release decision. When you get access to SAP BRH it will contain the predefined configuration setup in order to facilitate your own implementation, however it will not contain any "data" since this will have to come from your systems. It is a so called "PUSH" approach (from your source systems to SAP BRH) compared to a "PULL" approach (namely connecting to your systems and requesting data). If SAP BRH would have been designed with a "PULL" approach, this would have limited its capabilities to connect only to "SAP" systems but that would have not met the needs of the Qualified Person. In fact the Qualified Person needs to have data from several systems, not all (necessarily) made by SAP. 

CTM: Clinical Trial Management

LIMS: Laboratory Information Management System

DMS: Document Management System

QMS: Quality Management System

MES: Manufacturing Execution System

GBT: Global Batch Traceability

RIMS: Regulatory Information Management System

The above figure shows that:  

1. In order for the Authorized Person to release a Batch, they need to have information from different data sources. For example, information from manufacturing, supply chain process, quality and regulatory.  
2. The data needs to be copied from the data sources into SAP BRH, this is what is generally called "PUSH" integration 
3. SAP BRH provides a rich set of API to enable a very diverse set of data objects to be filled from the data sources 
4. If a customer has SAP S/4HANA, then SAP BRH enables some of the data objects to be directly transferred from SAP S/4HANA to BRH without additional programming efforts by the customers 
5. For some data sources, and for some data objects, the customer has to take care themselves on how to push them into the SAP BRH, using the API available. 
6. Beyond "incoming" API, there is also an "outgoing" API that enables the Release Decision to be automatically consumed by source systems for automatic enablement of release processes. 

Surely, that figure is only a simplification since the kind of checks possible is much more than the one shown there. The full list of release checks possible is growing from release to release of the product, as well as the kind of systems for which the SAP S/4HANA based integration in SAP BRH is included in the service. 

*The consumer of the outbound message can be SAP S/4HANA or other systems, since it is configurable.

Note

Future versions could have additional Entities.

In SAP BRH there are more than 40 different API (Event API service tiles for asynchronous communication, ODATAv4 API service tiles for synchronous communication).The APIs are either INBOUND (namely from outside SAP BRH to inside SAP BRH) or OUTBOUND (namely BRH is sending data out).

The diagram summarize the version 2.0 of SAP BRH API.

The circles in the middle represent the core entities, around which all or most of the other entities are connected.

Material / Plant / Batch is at the core of everything in SAP BRH.

The green circles are the API that have been added in version 2.0.

Release Decisions are the only "output" generated by SAP BRH, however since no "delete" is possible in SAP BRH, one can always check which data is present in SAP BRH.

How to achieve that is described in the API as well.