Interactions between systems are following the synchronous or asynchronous communication pattern. Synchronous communication is mainly covered via HTTP and handled by an Application Server, asynchronous communication is handled by a Message Hub / Message oriented Middleware (MOM). B1i is addressing both of the pattern and can be seen as a Message Bus, supporting full MOM and the integration centric part of an Application Server. Both the communication patterns have their pros and cons.
The synchronous communication is a direct communication between the involved parties. The sender gets immediate feedback which is an ideal situation from integration perspective. The big drawback is the availability – this communication works only in case the receiver is available. You can compare this communication with a phone call in the everyday life. Only if you reach the called party, you can talk to the communication partner.
The asynchronous communication is an indirect communication between the involved parties. The sender is handing over his information in form of a message to the message hub. The message hub stores the message on its side; afterwards the sender is closing the communication. There are typically multiple processing steps inside the message hub till the message is handed over to the receiver. The error handling of the message hub takes care that the message is handed over to the receiver once the receiver is available. The drawback here is the indirection in communication and the complex processing. When you talk to an answering machine in your everyday life, this is an asynchronous communication.
Even if the receiver is available in a synchronous communication, a failure in the network can falsify the information or even worse the line is cut in-between. There are many countries in the world with bad and/or very expensive infrastructures wherefore a direct communication is not possible and even in the perfect world you have normal system maintenance shutdowns. Therefore synchronous communication is not reliable. Furthermore synchronous communication can be used only for short interactions as the sender system is waiting for answer. Both communication patterns have their right to exist.
Both the frameworks B1iSN and B1if are supporting the synchronous and asynchronous communication. A typical example for synchronous communication is an iPhone or more general a web client, calling a (web)-service to retrieve data or to handover data to a particular system, e.g. SAP B1 or SAP R/3. Another example in B1if is the Xcelsius, calling a B1i service to retrieve data for a dashboard. All other communication, where you need reliable interaction, have to follow the asynchronous pattern. Typical examples are an SAP B1, sending an order to a fulfillment system, interaction with legacy systems via flat file or databases or consolidating data or synchronizing data with e.g. a reporting system.
Whereas the synchronous communication is covered in one processing step, the asynchronous processing is built in multiple processing steps. A processing step in B1i is called IPO. IPO stands for Inbound-Processing-Outbound and is one transactional unit (it is divided into individual, indivisible operations and succeeds or fails as a complete unit – ACID transaction). In case of multiple steps, the IPOs are connected via internal queues.
Synchronous Communication
Synchronous communication is triggered by incoming synchronous HTTP or Web Service calls, following the request-response pattern. The data is handed over via the HTTP Post. The inbound is creating the B1i message, providing the call information and the data in the message body and calls synchronously the subscribed processing step. In case there are zero or more than one subscribed steps, an exception is raised. The result of the processing step is handed over as the response to the caller.
Asynchronous Communication
Asynchronous communication is triggered by an incoming B1 event, an incoming RFC call, an incoming HTTP/SOAP call, by scheduler or existence of particular files in the file system. During the inbound phase the data is retrieved from the sender system and the B1i message is created, holding the trigger information and the sender data in its body. Optional additional data is retrieved to enrich the message. In B1iSN the message is handed over via the internal queue to the processing for the one BizStep (BIU), subscribed via the ObjectType. In B1if the message is handed over to all Scenario Steps (vBIU), subscribed to the incoming message identifier. The processing phase is mainly calling the transformation flow. The result is distributed to the outbound phase for all receiver systems via an internal queue. In case the processing flow is producing multiple outbound objects, there will be multiple messages in each of the receiver queues. The error handling of these processing patterns inside B1iSN and B1if will be covered in a follow-up post in this blog.
Graphical Flow Design - Processing Flow
The transformation flow is technically a B1iP bizflow (in B1iSN the main.bfd, in B1if the vBIU.bfd). The transformation flow is covering the conversion from sender to receiver schema. This is quite often just one xsl transformation. You can enrich the flow with so called flow atoms to cover conditional processing, iterative processing, conversions, additional transformations and external calls.