The task of B1if is to allow the customer’s SAP B1 system to collaborate with all the different touch points in his landscape. In the today landscape of a company there are many different touch points already and the number is growing very fast. Touch points are suppliers, external service provider, social networks, fiscal authorities, web shops, banks, etc. Due to the diversity in technologies and interface definitions, this task is typically manageable only by high-cost integration experts.
With B1if, SAP introduced a model to make collaboration affordable for everyone. Instead of asking you to ‘develop’ your individual collaboration scenario, the model knows what to do and provides you UIs to describe your task details. The model is based on a huge database with meta information which allows B1if to make your life as easy as possible.
Main task in collaboration scenarios is to handover data to a touch point or to retrieve data from a touch point. In B1if this task is done by a Call. During the processing of an Integration Scenario in B1if, there are three potential phases where calls could come into the play. During the inbound phase to retrieve data from the sender system in case your sender system did not handover the data already with the incoming call, during the processing phase in case you want to perform some calls to one or many other systems and during the outbound phase to handover the data to the receiver system.
Some of you will have recognized the magical IPO pattern (Inbound-Processing-Outbound), which can be found in many different areas in computer science. Even on highest level all computers in the world are following this principle. Inbound (e.g. keyboard, mouse, microphone, …) – Processing (central processing unit) – Outbound (e.g. screen, printer, loudspeaker). It’s always about IPO and so also in B1if you will find this principle on many levels.
Was it IPO in the overall scenario flow, also all calls in B1if are following the same principle and provide a generic pattern to give you always the same look and feel and not bothering you with technical details and protocol differences of different technologies. As B1if is a 100% xml based solution a call is always done by handing over parameters and an xml document which is called request document (inbound). The call is performed (processing) and hands over the result in the response document (outbound).
The request documents for different call types (DI (B1), JDBC (SQL), RFC (R/3), File, SMTP (send email), POP3/IMAP (receive email), HTTP, …) are totally different as they are reflecting the specification for the particular interface to be called. E.g. if you want to insert a new Business Partner entry into SAP B1 via the DI API, the DI API specifies exactly how to perform the call. It describes (interface definition) in which structure (schema) to hand over the concrete values.
If you design a new integration step in B1if (Scenarios->Step Design) you’ll find the three buttons Inbound, Processing and Outbound in the UI to specify the three phases mentioned above. Calls during the inbound phase are completely handled internally by B1if based on your input in the appropriate UIs. The calls in the outbound are also generated out of your definitions. The request document to be sent to the receiver system is based on the result at the end of the processing phase. The calls during the processing phase will be designed by using the graphical flow designer of B1if. In this designer you can assemble the flow to your needs by just adding Flow Atoms to perform calls in your flow.
B1if knows many details about the Business Objects of the SAP systems and about the APIs to be called, it knows which functions are available, which business objects and which services are provided and it knows about the parameters and the schema definitions. This knowledge is used by B1if to structure and to support your call definitions. For your convenience the parameter screens provide drop-down lists to specify the actual parameters for your call and take care of all interdependencies between the parameters. With release 1.5.0, the B1 Object calls, B1 Service calls and B1 Function calls are fully supported.
Inside the processing flow there are two types of call atoms available. The simple calls are easy to use as you just need to open the UI and enter some parameters. Simple calls are e.g. Call a B1 Function, Send a B1 Message (Alert), Call SQL, DIR File System Info, Upload/Download a file, Call B1 Object to retrieve data, … . The required request document for the simple call is generated automatically by B1if. The data call requires you to provide the necessary request document. Therefore a predecessor transformation step is needed to generate the request document to be handed over to the call. Data calls are all calls where you need to handover individual data, e.g. Call B1 Object/Service to insert/update data, Call R/3 to insert/update data, Call via HTTP or Send an email.
If you create such a call you will get asked to automatically create a predecessor xsl to prepare the request document. On button click you can generate a template for a request document for a particular call directly into the predecessor xsl document.
The generated request document provides you all information, available in B1if like the correct structure, the field names, if available the allowed values (enumeration) and the name of the corresponding database information like field type and field length. Using an xml editor (e.g. XMLSpy, embedded into B1if) you open the xsl document and apply the actual values into the generated template.
I wish you good luck in performing your calls in B1if. Now you are familiar with the conceptual background; with some practical experience you will see how fast you can create new Scenario Steps.