Technical Architecture Model

Let me give you an overview of the architecture and the components of the Integration Framework for SMEs (aka B1i).

Technical Architecture Model

RDBMS – Persistency
The Integration Framework for SMEs (B1i, or integration framework) runs with a standard Relational Database Management System (RDBMS). It is a prerequisite that the database provides access using JDBC. In the RDBMS the integration framework runs using its own eight tables.

On top of this physical, low-level storage, the integration framework defines its own XML persistency, called BizStore. This logical view is the structure you work with in the integration framework. The BizStore has a two-level hierarchy. The directories of the first level are datasets; the directories of the second level are groups. In the groups you find all documents.

The dataset names follow the inverse domain URL convention, for example The integration framework consists of multiple datasets with multiple groups. With the installation of the integration framework there are many datasets, groups and documents already available. The BizStore-URI uniquely defines the location of a document. The URI consists of the full path /dataset/group/document. The integration framework exposes the BizStore using WebDAV. WebDAV stands for Web-based Distributed Authoring and Versioning and is a standard interface specification for exposing data. Using this standard the integration framework allows any WebDAV client full and transparent access to the BizStore layer. A WebDAV client is for example the Microsoft Windows Explorer or the Altova XML editor. The WebDAV client allows you to work with datasets and groups like you work with folders and you can work with documents like you work with files in the file system. 

The integration framework runtime is developed in Java. It runs on Apache TomCat 6 which runs in the SAP Java Virtual Machine (JVM). The main component of the integration framework is the XCellerator. This component provides two options to access the persistency layer: The Persist BizAtom that you can use in an integration flow and the XSLT document() function, which is overlaid by the XCellerator, to be used inside an XSLT stylesheet.
The XCellerator controls all integration processes, handles the internal cache and is responsible for the transactional consistency.
The integration framework processes are IPO steps (Inbound, Processing, Outbound). The XCellerator processes IPOs as ACID transactional units. IPO steps are defined in the IPOXML language, in which you specify the primary IOs, secondary IOs and the process flow.
The inbound (I) and outbound (O) phase are in the responsibility of the Adapter Framework. With the adapter framework the integration framework context connects to the non-XML world. The adapter framework contains many Adapters to connect to different APIs and technologies in Business Systems, and provides an RFC Adapter, DI Adapter, File Adapter, JDBC Adapter, HTTP Adapter, SOAP Adapter, and so on.
The BizProcessor handles the processing (P). It controls the processing of a flow which is defined in the BizFlow language. This language supports sequential, conditional and for-each processing and allows assembling flows based on BizAtoms. The xform runs an XSLT transformation, the call calls an adapter, the persist accesses the BizStore, the branch_unbranch controls conditional flow processing, the split and join control the for-each processing and the include allows you to call other BizFlows.
Multiple IPO steps, each holding exactly one BizFlow, which contains multiple BizAtoms, are bundled as a B1i application. The integration framework supports multiple B1i applications to run simultaneously. The model of the integration framework itself is a B1i application. 
Beside the XCellerator, the integration framework runtime includes the Java Crystal Report Runtime. It is used out of the XCellerator to run reports from inside integration scenarios.

3 Nested Languages

There are three different layers of processing involved to run an integration scenario. The XCellerator provides the XML based connector language IPOXML to specify IPO steps. Inside the IPO the bizflow is processed based on the BFD (Bizflow Definition Language). Transformations by the xForm Atom are processed by the inbuilt XML processor.

Integration Model
The integration framework model defines integration scenarios and connectivity points.
1. The integration scenarios definitions are Scenario Steps (vBIU = Business Integration Unit). Each scenario step consists of an Inbound definition, an Outbound definition and its Process Flow. The Process Flow is a BizFlow. It therefore also supports sequential, conditional and for-each processing. The process flow consists of Processing Atoms that an integration developer can access using the Graphical Flow Designer. The graphical flow designer represents the particular integration logic. The atoms are implemented as Include BizAtoms and they cover powerful out-of-the-box call and transform functionality for many different purposes. The Graphical Flow Debugger is part of the graphical flow designer. It especially addresses the requirement to debug flow languages.

Multiple scenario steps are bundled in a Scenario Package. The scenario package is the software logistic unit of the integration framework; you can import or export scenario packages, you can set them up and activate and deactivate them. A scenario step and a scenario package belong to a specific namespace. Following the isolation principle, the integration framework can run multiple scenario packages from different namespaces simultaneously without them interfering with each other.

2. The System Landscape Directory (SLD) registers the connectivity points. Here you create SLD entries based on predefined SysTypes (System Types). Each SysType has one or multiple Connectivity Types, which describe the call to access the system data. Using a navigation tree you can administer all systems and connectivity in your landscape. You can add, modify or delete SLD entries and ping the systems.

Entity Relationship Diagram
To give you even more insights, let me provide you with the following entity relationship diagram:

ER Diagram

SAP defines system types (SysTypes) that you can use and delivers them in the integration framework repository. They define a particular type of a system or connectivity. Each SysType can have one or multiple Connectivity Types, for example SAP Business One has the DIAPI and JDBC connectivity types. Each connectivity type can be used in multiple SysTypes. The JDBC connectivity type, for example, is part of the B1.8.8 and in J.AnySystem SysTypes. Each connectivity type defines one or multiple schemas to specify the Payload Type.

Scenario Packages have one or multiple Scenario Steps. Each scenario step belongs to exactly one scenario package. Each scenario step has exactly one sender SysType and no or one receiver SysType.

During setup you create systems in the SLD based on the SysType definitions. You can create multiple instances of each SysType. An instance is called SysId Entry, the unique number to address this entry is called SysId. In the SLD you have one or multiple SysId entries. With the scenario setup user interface you setup a scenario package by defining concrete SysId entries as sender and receiver systems for the different scenario steps. After setup you can activate or deactivate a scenario package instance. For each selected and correctly setup scenario step the integration framework generates the necessary processes (IPO step instances). For each scenario package you can run exactly one instance.

User Interface
The first picture shows the Integration Designer and the Integration Administrator that access the integration framework using a Web browser. The integration designer uses the integration framework as his or her development environment to create new integration flows. The integration administrator uses the various administration functions and monitors to administer the productive integration framework.

With the integration framework you can work as an Integration Designer or Integration Administrator using a standard Web browser. This allows you accessing the integration framework at any location without any local installation. You can connect to the integration framework using http or https.

Both, the design and the administration environment are bundled in one application. You can access the application calling the following URL: <protocol>://<ip-address>:<port>/B1iXcellerator/exec/dummy/!defdoc=/

You can define your own tool for different purposes/roles in your company, e.g. for a developer or the administrator.

The integration framework provides scenario design user interfaces including the graphical flow designer and the inbuilt test environment for the integration designer. For the integration administrator the integration framework provides full scenario control, the System Landscape Directory, maintenance functions and several monitoring options including the graphical flow debugger.

The Control Center provides all functionality for low-level configuration and trouble-shooting.   

User Interface


Recommend this post to your contacts:

This entry was posted in B1if, B1iP, general. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *