openSAP

In Action - Integration Framework for SAP

Business One
Week 01 Unit 01

00:00:05 Hello and welcome to Week 1, Getting Started for the course In Action – Integration
Framework for SAP Business One.
00:00:13 My name is Mario Fetzner and I am working in the solution expert department for SAP
Business One.
00:00:20 I am supporting SAP Business One partners in product enablement and pre-sales activities. In
this unit, I will tell you about the course overview and structure.
00:00:33 The integration framework of SAP Business One is a platform for developing and running
integration solutions between SAP Business One and other systems.
00:00:44 In this four-weeks course you will learn how to use the integration framework to create, test,
and run integration scenarios.
00:00:56 In this course, you will see the integration framework for SAP Business One in action. You will
get experience in developing integration solutions for customers,
00:01:08 and you can take this course at two levels: First, watch the videos for each unit and test your
understanding by taking the quizzes.
00:01:17 Second, in addition, sign up for a test system and get hands-on practice using guided
exercises.
00:01:25 Then explore the integration framework on your own. This openSAP course is structured in
four weeks: Week 1 – Getting Started,
00:01:36 Week 2 – Scenario Design Basics, Week 3 – Integration to SAP Business One, and Week 4 –
Integrating SAP Business One Companies.
00:01:47 Each week consists of lecture and demos, a self-test to test your knowledge after every unit,
and optional hands-on exercises.
00:01:57 At the end, there will be a final exam to test the knowledge you have achieved after the four-
weeks course.
00:02:04 Of course, there will be discussions and online forums during the whole course. From a course
rating perspective, you can achieve a maximum of 30 points per week.
00:02:17 The final exam is graded with 120 points, which is in total 240 points. Integration solutions
typically bridge systems running different communication protocols,
00:02:32 and to facilitate this they convert and process data internally in Extensible Markup Language
(XML).
00:02:41 The integration framework is no different,
and you need a good working knowledge of XML in order to develop integration solutions.
00:02:50 Take the quiz to assess your XML knowledge;
if you need more information on XML, you can complete the XML Tutorial while accessing this
webpage.
00:03:04 If you want to have access to a test system, you can sign up for a test system in the cloud. The
test system is available at very low cost for a month.
00:03:14 The system is preconfigured with SAP Business One, the integration framework, and a test
database.
00:03:21 Take advantage of this unique opportunity to get hands-on time using the integration
framework. During this course, you will see integration scenarios that involve
00:03:34 Structured Query Language (SQL), Hypertext Transfer Protocol (HTTP), and JavaScript
Object Notation (JSON).
00:03:44 If you have limited experience of the above, click the links to visit the respective sites to learn
more.
00:03:53 Thank you for attending this unit.

2
Week 01 Unit 02

00:00:08 Hello and welcome to Week 1, Getting Started for the course In Action – Integration
Framework for SAP Business One.
00:00:16 My name is Mario Fetzner, and in this unit we will have a quick look at the integration
framework – market focus.
00:00:25 When completing this unit, you are able to describe common requirements for integration
involving a small business,
00:00:32 learn about SAP Business One and the integration framework component, and explain the
concept of a scenario.
00:00:41 First I want to give you some integration examples for a small business. A small business is
not an island.
00:00:50 A small business might be a subsidiary or franchisee of a larger business. There could be a
need for master data to be replicated
00:00:58 from the point of creation to a headquarter’s system. There might also be a need for
consolidating the accounting
00:01:06 and rolling up financial results to headquarters – financial consolidation. An example could be
a car dealership.
00:01:13 This kind of tight integration involves extending a business process across multiple, disparate
systems that may each run different applications and APIs.
00:01:24 All these businesses can connect to the integration framework. Some small businesses may
be part of the supply chain for another business,
00:01:35 and might need to conform to data interchange standards set by the other business. Tight
integration would be needed to ensure that,
00:01:44 whenever a sales order is generated on the main business, a purchase order is also sent
electronically to the supplier
00:01:52 to order the goods needed to fulfill the sales order. This involves the exchange of transactions
between the two systems.
00:02:02 In the third example a small business has its own ecosystem where it needs to involve other
businesses in its business processes.
00:02:11 For example, a small business might purchase raw materials from suppliers, and sell finished
products to customers.
00:02:19 In the connected world, small businesses need to integrate with other entities in order to
compete in today’s global business climate.
00:02:28 Examples are point of sale, close collaboration with parts suppliers or customers,
communicating electronically with tax authorities.
00:02:39 Our small business will most certainly have to interact with government and other official
entities.
00:02:45 Perhaps they need to develop an e-commerce site? Let us have a look at SAP Business One
and the integration framework.
00:02:56 SAP Business One is a fully functioning enterprise resource planning application, ERP,
specifically designed and priced for small businesses.
00:03:05 SAP Business One is really like an integration platform for a company’s complete core
business processes.
00:03:12 SAP Business One integrates all business management functionality: Sales, purchasing,
accounting, inventory management, production,
00:03:23 service and analytics in a single database. So all the data is already integrated in the database

00:03:31 which makes using it for integration much easier. SAP Business One is used by customers in
over 150 countries
00:03:41 and around the world in 27 languages. While SAP provides 43 localizations for the product,

3
00:03:48 our partners have adapted these localizations to fit the needs of many other countries. This
means that you can use the integration framework to connect businesses globally.
00:04:02 SAP Business One is designed for partners to extend the core functionality using the SDK and
service layer APIs.
00:04:11 The integration framework is part of the SAP Business One solution stack and enables SAP
Business One to send, publish and exchange data
00:04:21 with external systems and applications to access or consume data from external data
providers.
00:04:29 The integration framework uses the SDK and service layer APIs to integrate to and from SAP
Business One.
00:04:40 The integration framework serves as an integration hub and is designed specifically for small
businesses.
00:04:47 It runs on Windows and/or Linux and has a low overhead and small footprint. It is simple to
install and easy to get up and running.
00:04:57 Yet at the same time it is robust and scalable. It provides the necessary error handling,
tracking, and logging
00:05:05 which allows the consultant to focus on the business logic needed for the integration. The
integration framework can support exchange requests and data
00:05:16 between many different systems running concurrently. Importantly, it uses established
integration standards
00:05:23 such as Extensible Markup Language (XML) and Extensible Stylesheet Language
transformations (XSLT).
00:05:32 At runtime, the framework automatically converts incoming data to XML format. XML is a
natural language for integration purposes
00:05:43 because it is vendor-neutral and machine-readable. Therefore you do not need to understand
proprietary APIs.
00:05:51 You can use the integration framework to connect to SAP and non-SAP systems, as well as a
wide selection of systems and services, including web and cloud applications.
00:06:04 SAP Business One is able to integrate easily to large SAP systems as a subsidiary or supplier
to larger systems.
00:06:16 Scenarios are developed to implement an integration solution on top of the integration
framework platform.
00:06:23 A scenario models the business integration requirement from end to end. You define scenarios
in the user interface of the integration framework.
00:06:34 As a technical consultant, you can define new scenarios to meet the specific integration needs
of a customer.
00:06:42 No programming knowledge is needed to develop these scenarios. These scenarios are easily
transported and plugged into the customer’s system.
00:06:52 All scenarios use the underlying platform services, such as flow of data, error handling, logging
and tracking, and guaranteed delivery of data.
00:07:03 As mentioned previously, all data entering the integration framework is converted to XML. This
is made possible by adapters for various connectivity types.
00:07:17 Several predefined scenarios are provided and can be run out of the box after you install SAP
Business One.
00:07:25 Starting clockwise from the top left: Standard integration scenarios for SAP Business One.
00:07:31 A list of the scenarios is shown here and includes the support for dashboards and mobile apps
within SAP Business One,
00:07:39 and integrations to the Ariba Network, to SAP Hybris Cloud for Customer and SAP Customer
Checkout.
00:07:47 To find out more about these provided scenarios, you can access them from the integration
framework user interface

4
00:07:54 and find documentation on how to run them. Subsidiary integration scenarios.
00:08:01 These scenarios are available for customers and provide comprehensive integration between
SAP Business One and SAP ECC, SAP BW or S/4HANA systems.
00:08:15 Intercompany integration scenarios. These scenarios are available for purchase by customers

00:08:20 and provide comprehensive integration between SAP Business One databases. Possible
integration scenarios.
00:08:29 This is the focus for this openSAP course and allows you to develop your own scenarios to
integrate SAP Business One to non-SAP systems,
00:08:40 to web- and cloud applications and services, and so on. To summarize this unit: Small
businesses need to integrate with other systems
00:08:52 as subsidiaries, as suppliers, and within their own ecosystem. The integration framework for
SAP Business One is a cost-effective, robust platform
00:09:03 for developing and running small business integration solutions. This is provided with the SAP
Business One license at no extra charge.
00:09:13 The integration framework follows established integration standards such as Extensible
Markup Language (XML),
00:09:21 Extensible Stylesheet Language transformations (XSLT) and web standards such as HTTP.
Scenarios implement the business integration requirements
00:09:32 and run on top of the integration framework platform where they make use of the error
handling, logging and tracking,
00:09:40 and guaranteed delivery of data. You can easily and quickly define integration scenarios
00:09:47 using the in-built development platform to provide your small business clients with custom
integration solutions,
00:09:55 integrate your own solutions or add-ons for a small business. In the next unit, you will see how
the integration framework works internally,
00:10:05 including the use of XML. Thank you for attending this unit.

5
Week 01 Unit 03

00:00:08 Hello and welcome to Week 1, Getting Started for the course In Action – Integration
Framework for SAP Business One.
00:00:17 My name is Mario Fetzner, and in this unit, I will tell you how the integration framework works.
When completing this unit, you are able to describe
00:00:29 the use of Extensible Markup Language (XML) in the integration framework and list the main
payload types in an XML message.
00:00:40 We introduced scenarios in the previous unit. The scenario is essentially a container for one or
more steps.
00:00:48 The logic for the integration is implemented at the step level. Each step represents a specific
integration flow of data,
00:00:57 for example, from a sender system to a receiver system, or a request to an application or
service with a response.
00:01:07 If the flow of data is very simple, only one step is needed. If the flow of data is complex, you
can break it down into multiple steps.
00:01:17 Each step responds to a trigger, which might be a timer, an event from SAP Business One, or
a call from an external system sender. The step executes when triggered.
00:01:29 You can also trigger a step by calling it from another step. Steps are either asynchronous or
synchronous.
00:01:37 An asynchronous step transmits data from a sender system to a receiver system. A
synchronous step makes a request to another system
00:01:47 or receives a request from another system – there is no receiver system involved. Note: The
step can perform other processing in addition to the transmittal of data.
00:02:00 You will see examples of this in Weeks 2 to 4. A scenario step, when triggered, runs in three
different phases.
00:02:11 The first phase is the Inbound phase. In the Inbound phase, calls or events retrieve the data
from the sender using a predefined adapter.
00:02:21 The adapter is selected when the scenario step is defined. The integration framework provides
different adapters
00:02:31 to handle the conversion of data from various proprietary APIs to XML format. Some examples
of adapters include JDBC, HTTP, and so on.
00:02:44 When a timer is defined as a trigger, then an adapter is not necessary. The timer starts the
process after the defined time settings.
00:02:54 The adapter converts the incoming data to XML messages which are processed by the next
phase.
00:03:01 The integration framework always processes the data internally as an XML message whatever
the format of the incoming data is.
00:03:13 The Inbound phase hands over the XML message to the next phase, the Processing phase.
The handover from phase to phase is done via internal queues.
00:03:24 The XML message containing the data is processed by the integration framework. Depending
on how the step is configured,
00:03:32 there might be calls to external systems or conditional processing. These calls might result in a
change or enhancements to the data.
00:03:43 At some point in the processing, the data is transformed into the XML format required by the
receiving system (asynchronous step only).
00:03:52 The rules for the data transformation were defined by the scenario developer using XSLT,
Extensible Stylesheet Language Transformations.
00:04:05 The data is still in XML format throughout the Processing phase. The Processing phase may
perform other functions in addition to transforming the data.

6
00:04:17 This depends on the business scenario. The final phase is the Outbound phase as soon as a
receiver is defined.
00:04:27 Then the Outbound phase only applies to asynchronous steps, in which there is a receiver
system for the transformed data.
00:04:36 If the whole process is managed inside of the Processing phase, then there is an outbound
and a receiver definition is not possible.
00:04:45 The Outbound phase receives the final XML from the Processing phase, and the outbound
adapter converts the data
00:04:53 into the actual non-XML format required by the receiver. The adapter hands over the final data
to the logical receiver system.
00:05:03 The integration framework handles the transmission of data reliably over the network. XML is a
natural choice for integration as it was designed
00:05:16 to describe and carry data in both, a human and machine-readable format. Using self-
interpretive tags makes XML almost a universal data format
00:05:28 and the natural choice for open data interchange. XML documents contain elements within
tags.
00:05:35 If you are familiar with HTML, then an XML document will look familiar. In XML, the markup is
contained within the tags, and the content is outside of the tags.
00:05:48 XML always begins with a start-tag <element>, and ends with an end-tag </element>. So let
us look at the actual message from the integration framework.
00:06:00 The XML message that the integration framework processes during a step contains different
sections that are added along the way
00:06:08 to produce the final message for the Outbound phase. The Body tag is what we are most
interested in
as this contains the data within Payload tags.
00:06:20 There are different payload sections added at each phase of step processing. The payload
types of the XML message
00:06:29 depend to some extent on the step design, but can include: Type T contains a description of
the trigger for the step.
00:06:38 Type S contains the incoming data from the sender, converted to XML. Type X shows any
internal transformation of the sender message.
00:06:49 This section only appears if you have designed the scenario to include an intermediate
transformation during the step processing phase.
00:06:59 Type C shows information regarding a call from the step to an external system, for example, a
call to a SQL database.
00:07:09 In this case the result set from the query will also be shown. The type R section contains the
final XML message at the end of step processing.
00:07:20 The type R2 section shows the receiver message in XML that will be handed over to the
outbound adapter.
00:07:28 This section is not completed until the final transformation of the data. To summarize this unit:
00:07:37 Step processing involves three phases – Inbound, Processing and Outbound. The integration
framework converts all data it receives to XML messages
00:07:49 and processes data internally as XML messages. Additional payload sections are added to the
XML message during step processing.
00:07:59 This can include external calls to enrich the data, as well as the transformation of the data into
a final XML representation.
00:08:09 The final XML is handed over to the Outbound phase and the adapter for transmission. In the
next unit, you will see how to set up the integration framework
00:08:20 as a development environment to start your scenario development. Thank you for attending
this unit.

7
Week 01 Unit 04

00:00:08 Hello and welcome to Week 1, Getting Started for the course In Action – Integration
Framework for SAP Business One.
00:00:17 My name is Miriam Rieger and I am working in the roll-out team for SAP Business One. I am
responsible for the roll-out of different integration solutions,
00:00:27 like the integration framework for SAP Business One, the intercompany integration solution,
and other provided integration scenarios.
00:00:36 In this unit, I will tell you about the development environment. The objectives for this unit are to
explain the differences
00:00:47 between the development and productive environments of the integration framework and to
switch between these two profiles: the development and productive.
00:01:01 The integration framework features a web browser-based user interface. This user interface is
the same for both operations,
00:01:10 administration and scenario development. There are two different profiles available, a
productive profile and a development profile.
00:01:21 The productive profile covers the control and monitoring of running scenarios, as well as the
import and activation of scenarios into a customer environment.
00:01:34 The development profile includes the building blocks for defining the scenario inbound,
processing and outbound phases.
00:01:43 In this profile, the development profile, the integration framework provides an internal
embedded XML editor,
00:01:52 as well as internal tools for testing and debugging. The user name B1iadmin is predefined
when you install the integration framework.
00:02:04 After the installation, it is also possible to create more users with different roles and privileges,
such as administration and deployment.
00:02:17 The integration framework can operate in one of two modes, also called profiles, either as a
productive system or as a development system.
00:02:28 This is controlled by the system profile. A system profile brings together the recommended
configuration settings in one place,
00:02:38 optimized for a productive system or a development system. Each mode has a color-coded
upper line.
00:02:48 As you can see on this slide, it is blue when you are working in the productive mode, and a
golden color when working in the development mode.
00:02:59 After the installation, when you are opening the integration framework the first time, it opens in
the productive mode.
00:03:09 If you want to create and test new scenarios, you need to switch the system profile to a
development system.
00:03:18 The development mode contains the recommended configuration settings for scenario
development, testing, and debugging.
00:03:28 Please take care to work in the correct mode. It is very easy to switch between development
and productive mode.
00:03:36 After you have made the switch, you need to restart the integration service to take effect. For
running the integration framework in productive mode or for developing scenarios,
00:03:51 each system profile contains recommended and predefined settings. Because these are just
recommendations,
00:04:01 you can change any of the settings at any time if you need. This can be handled very flexible.

00:04:10 As mentioned in the slide before, a restart of the integration service is necessary to take effect.

8
00:04:17 In this slide, I want to point out some of the settings. The Session Timeout value, as you can
see here,
00:04:26 is 20 minutes for a logged-in user in the productive profile. In the development profile, it is 500
minutes.
00:04:35 Support for remote WebDav client such as an external XML editor, is enabled in the
development profile, not in the productive profile by default settings.
00:04:48 A development prefix can be set in the development mode. This is only applicable in the
scenario development,
00:04:56 and there you can enter a three-character string. This string will be added to the scenario
name of all scenarios that you create.
00:05:06 This allows you to identify scenarios developed by your company. To add a prefix is
recommended.
00:05:15 If you do not add a prefix, the system uses a z instead of the prefix. Before you create the
scenario package and steps,
00:05:25 you should decide on the prefix and a naming convention for your scenarios. Scenarios from
SAP can be identified by the prefix SAP.
00:05:38 If you want to modify a scenario, you do this in the development profile. Scenarios can also be
modified in the production profile but it is not possible to test them.
00:05:51 Debugging a scenario is only possible in the development profile, it is not available in the
productive mode.
00:05:59 Detailed logging should be avoided as it can degrade system performance. But for a
development environment it is advantageous
00:06:09 to log all details for a running scenario. In the default settings, the XML and XSL files are able
to open in a productive mode too,
00:06:20 but they will be shown in a web browser. The embedded XML editor is disabled in the
productive profile,
00:06:29 It is only enabled in the development profile in the default settings. Let us go to the system and
have a look at this.
00:06:41 Here you can see my system. And when you open your system for the first time, you are
working in the productive mode
00:06:50 as you can see here with the blue-colored upper line. If you want to develop a scenario,
00:07:00 we recommend to change the productive mode to the development mode. You can do it here
under Maintenance, and there you have the System Info.
00:07:13 And here you see that the system profile is at the moment Productive System. Before you
change it, I want to show you also here in the configuration message log,
00:07:26 as you saw on the slides, that when you are in the productive mode, the Log Level is only an
Infoset.
00:07:38 You can change it here, change it to Full message. But I want to keep it in the productive
mode to have only an Infoset.
00:07:51 To change the system to the development profile, I go to System Info, I select here the
Development System,
00:08:06 and I confirm the message that I want to change to the development system. And I get another
message from the system
00:08:18 that a manual restart of the integration service is necessary. I go here, to the services.
00:08:33 In the services, I go a little bit down to the integration service, and I restart them. I can close
this window, and I have to restart the integration framework again.
00:08:58 It takes a few seconds. I just log on again, and you see that the color has changed from blue to
golden.
00:09:12 And when we go under Maintenance – just a second – to System Info, you see that we are
now in the development system.

9
00:09:28 If you do some changes here under System Info, you have to restart the integration services to
take effect.
00:09:39 I want to click on this button, and there you see the differences between the productive
environment and the development environment.
00:09:51 As you saw on the slides, it is the Session Timeout of 20 or 500 minutes. Here, there are the
Log Levels. It is only Infoset. For the development, it is Full message.
00:10:06 And we have here also some topics activated like the Message Log, B1 Event Monitor. Or
here: Record Test Messages, Allow Active Step Modification
00:10:18 for the development environment. On the productive environment, you see this setting, the
Local Access Only,
00:10:28 and this means that you have to work on the local machine to have access to the system. You
also see some of these settings, which we saw here, on different places,
00:10:53 for example in the configuration of development environment or, as I have shown you a few
seconds before in the message log.
00:11:03 You see here the settings; and here you have also the possibility to change the development
prefix if you defined your naming convention,
00:11:16 you can enter the three digits, the three characters in this field, just save it and you have it, and
when you create scenarios,
00:11:26 the system always adds this prefix to your scenario name. Let us go back to the slides.
00:11:39 In this unit, you learned about the two different modes, the productive and development profile.

00:11:46 You also learned to switch between these two profiles. In the next unit, you will learn about the
BizStore,
00:11:54 which is the logical database where scenarios are stored. Thank you for attending this unit and
see you in the next unit.
00:12:03 Bye-bye.

10
Week 01 Unit 05

00:00:05 Hello and welcome to Week 1, Getting Started for the course In Action – Integration
Framework for SAP Business One.
00:00:15 My name is Miriam Rieger, and in this unit I will tell you about working with the BizStore. The
objective of this unit is to define the purpose of the BizStore database and how to access it.
00:00:35 In the previous unit, you saw that the integration framework features a web browser-based
user interface. The architecture of the integration framework includes a relational database
00:00:47 as a persistent store for deploying developed solutions. There is a logical interface layer called
the BizStore.
00:00:56 The BizStore is the XML persistency layer and logical storage. When a scenario is created, it
is stored in the BizStore
00:01:06 together with the respective XML documents. There are two ways to access the stored
scenarios and XML documents.
00:01:17 The first way is using the embedded XML editor. The integration framework has a built-in,
rudimentary XML editor
00:01:27 that can be used to modify XML documents for a scenario. You invoke this XML editor from
the browser interface.
00:01:38 A second way is using an external XML editor. You can use your preferred XML editor if it
supports WebDAV.
00:01:49 When you use a WebDAV XML editor, you access the BizStore layer directly. To access the
BizStore you typically use a URL and then browse for the appropriate scenario.
00:02:04 Using a WebDAV tool also gives you the option to develop your scenarios offline by
downloading the documents from the BizStore, updating them offline,
00:02:17 and then uploading them to the BizStore. When you access the BizStore directly from a
WebDAV tool,
00:02:27 you will see a structure similar to the structure shown here, with different expandable nodes.
00:02:37 This view of the BizStore folders is not available when you use the embedded XML editor. I will
show that later in the demo.
00:02:47 Scenario packages are stored in the com.sap.b1i.scenarios.design area of the BizStore. You
will also see that later.
00:03:01 Scenario packages are identified with the prefix vPac and the development prefix you entered.
In this example, it is the scenario package vPac.sap.ICPurchasing.
00:03:19 The scenario steps are identified with the prefix vBIU, Business Integration Unit. You should
develop a naming convention so that your scenario packages are easy to locate.
00:03:39 Let us go to the demo to see the BizStore. I will switch to my system.
00:03:48 As I said in the slides, you have two possibilities to enter the XML editor. The first one is that
you use the external XML editor.
00:04:01 For this one, I am using here Cyberduck to enter it. And we enter the BizStore. You see it
here, you see the folder structure.
00:04:13 And as I said in the slides before, you find your scenarios here under scenarios.design. When I
open it, you see the first level; these are the data sets. I will move a little bit down.
00:04:34 You see here many data sets. Here are some of our units we will create later. But you also see
some of the SAP scenarios. Let us move a little bit down.
00:04:51 For example here, with the POS, this is for the point of sales solution. Let us go up to my
scenario.
00:05:05 And when I open it here, you see the groups and the related documents here. If you want to
work with the external editor, you go to the relevant document and you open it –
00:05:23 not here, just a second – by using… In my example, I am using Notepad to edit this document.

00:05:39 This is the external editor. Let us go to the integration framework itself.

11
00:05:48 There you find the internal XML editor here, under Tools. And here you have the XML Editor.
00:06:00 When you are using the internal editor, you really have to know each node. There is no
structure, no folder structure as we saw in Cyberduck.
00:06:12 Here you have to select each node individually. We have also to move down to the
scenarios.design. Then I say Select.
00:06:29 Then I have to choose the scenario. I take this one. Say: Select. And the respective document,
let us take this one. Say: Select.
00:06:44 And then I can click on Open. And this is the internal, embedded XML editor.
00:06:55 If you are using the internal XML editor, you can also add this view directly from the process.
This means, when you are working in a scenario,
00:07:10 let us move to Scenarios, and Step Design, you have to select the scenario. I take this one.
00:07:22 And when I go to Processing, I have here each atom, and then you can go directly to the atom.
And if you click on it, you see the internal XML Editor and you can work here too.
00:07:41 It is the same as you saw before via Tools, and XML Editor. During your work, when you are
creating new scenarios, all of them are stored in the BizStore.
00:08:00 So, let us go back to the slides. And in this unit, you learned about the BizStore, the logical
database.
00:08:16 You can open and edit XML documents from the BizStore, from the browser interface. The
documents will open in the embedded XML browser, which is a rudimentary XML tool.
00:08:29 You can use a fully functioning external WebDAV XML editor to access the BizStore structure
directly.
00:08:37 And in the next unit, you will learn about the scenario building blocks that are provided for you
to define scenarios.
00:08:47 Thank you for attending this unit. And hopefully, I see you in the next unit. Bye, bye.

12
Week 01 Unit 06

00:00:09 Hello and welcome to Week 1, Getting Started for the course In Action – Integration
Framework for SAP Business One.
00:00:19 My name is Miriam Rieger, and in this unit I will tell you about the scenario building blocks. The
objectives in this unit are to describe the overall process for defining a scenario
00:00:35 and to explain the building blocks for defining a scenario step. The development environment
of the integration framework allows you to develop scenarios
00:00:48 using point-and-click options by selecting from dropdown menus. No programming expertise is
needed to develop a scenario.
00:01:00 To define a new scenario, the first thing is to define the package and provide a name. The
prefix that you specified in the development profile will be added to the package name.
00:01:14 Then define each scenario step and associate it to the package name. For each scenario step,
define the Inbound, Outbound and Processing phases.
00:01:28 The Outbound definition is only required for asynchronous steps, where data is sent to a
sender system.
00:01:39 A step models a specific interaction between two systems. These interactions can be
synchronous or asynchronous,
00:01:48 and you can have a mix of synchronous or asynchronous steps in the package. For a simple
business process with a single interaction, there will be just one step.
00:02:02 For a more complex business process with multiple interactions, there can be several steps. A
synchronous communication is a direct communication between the involved parties.
00:02:16 It follows a request-response pattern. The sender, the caller makes a request which triggers
the step processing.
00:02:25 The processing may make calls to external systems to enrich the data. The result of the
Processing phase is handed back to the caller as a response, immediately.
00:02:38 The result has to be handed back promptly during the step processing, otherwise it will run into
an error.
00:02:48 Asynchronous communication is triggered by an incoming event, call, or by a timer. During the
Inbound phase the data is retrieved from the sender system.
00:03:01 The step processing may make calls to external systems to enrich the data. The data is
transformed and passed to the Outbound phase
00:03:13 for the receiver system at any time. In the design for the step, you decide how the step will be
triggered,
00:03:23 which system types communicate with each other, how the integration framework will
transform the message,
00:03:31 and if any other processing will occur, such as calls to external systems. The inbound channel
describes this type of sender system
00:03:41 and you can select the API that the integration framework will use to retrieve the incoming
data. The inbound channel options are HTTP, file, void if the scenario is triggered by a timer,
00:03:57 Web Service, SAP Business One and SAP ERP. Please be aware some inbound channels are
only available in newer releases.
00:04:09 The outbound channel describes the type of receiver system, and you can select the API that
the integration framework will use to hand over the data.
00:04:19 The outbound channel options are the same as the inbound channel options: Web Service,
HTTP, file, database, void for synchronous steps,
00:04:31 SAP Business One and SAP ERP. For the Processing phase, you select atoms using a
graphical design tool
00:04:42 as you can see it here in the picture on this slide. Atoms are predefined functional units that
you can assemble into a sequence.

13
00:04:53 Atoms can be used for calling an external system such as an SQL database or email. Each
atom receives the inbound message, performs its tasks,
00:05:04 and hands over an outbound message to the next atom. In the BizFlow designer you can
define the step processing in the integration framework.
00:05:18 Initially the processing flow contains a start and end control structure with a single atom in the
middle.
00:05:27 This is a transformation atom that you can use to format the data into the final format for the
receiver or caller. The name of this atom is final.
00:05:38 This atom provides an Extensible Stylesheet Language file (XSL) that you use to transform the
data into the final structure for the receiver or caller.
00:05:50 This aspect will be covered in more detail in the next unit. You can select additional atoms to
add to the processing.
00:06:02 To add an atom, choose the arrow in the start control structure. A list of available atoms will
open, and you can choose from the list.
00:06:12 Each atom also contains an arrow so that you can add subsequent atoms to the processing
flow.
00:06:21 Let us go to the system and see how it works. In the system, you go to Scenarios and
Package Design.
00:06:36 And to add a new scenario you click on this plus icon here. And then we create a new scenario
and we add the name here.
00:06:47 In my example I will call it OpenSAPScenario, and I click on the tab. Then the system
automatically enters or adds the defined prefix –
00:07:00 it is edu in my system – to the scenario name. I select here, in the field Authentication, No
Authentication
00:07:14 and then I can save this new scenario. Then I go to Step Design, and here I have to select my
scenario.
00:07:34 Here I have my OpenSAPScenario. And then I can enter here a name for this scenario step.
Here you define the inbound channel,
00:07:57 and the outbound on this site. When I click on Processing, the BizFlow opens, and I see here
the final atom.
00:08:12 To add a new atom I click on this grey arrow, and I can select from the list which kind of atom I
want to add. In this case I want to call SQL. I select it.
00:08:30 And I add this new atom to the process, and I can close the window. And this new atom is
added to the process.
00:08:49 When I finished everything, I have to save this definition. If you want to delete a scenario, you
go to Package Design
00:09:04 but first you have to be sure you work in the correct prefix. Then you can select the scenario
which you want to delete
00:09:17 and you click on the trash icon to delete this scenario. The first message here is about the
deletion. And I say Yes or OK. I want to delete it.
00:09:32 And the second message, the system message is about archiving, that it is recommended to
archive the package.
00:09:42 If you do not want to archive the package, then click on Cancel. And the scenario package is
now deleted.
00:09:53 Let us go back to the slides. And in this unit, you learned the overall process for defining a
scenario.
00:10:06 It is: define the package, define a step and associate it with the package, and then define the
Inbound, Outbound and Processing phases of the step.
00:10:18 Then make simple selections from the building blocks – the inbound channels, processing, and
outbound channels.

14
00:10:27 Using the BizFlow Designer you can easily add atoms to the processing flow. In the next unit,
you will see how to transform data using the transformation atom.
00:10:42 Thank you for attending this unit, and see you in the next unit. Bye, bye.

15
Week 01 Unit 07

00:00:08 Hello and welcome to Week 1, Getting Started for the openSAP course In Action – Integration
Framework for SAP Business One.
00:00:19 My name is Annemarie Kiefer. I am a member of the integration framework development team,
and in my role as a User Assistance Development Architect,
00:00:29 I am providing all documentation for the integration framework. In this unit, I will give you an
introduction to data transformation.
00:00:43 The objective of this unit is to explain the process for transforming the XML message during
integration framework processing
00:00:54 and to present some XSL statements that are commonly used in data transformation. The
XML message needs to be converted
00:01:07 so that it describes the output structure of the data required by the receiver system. For
example, your input data from the sender might be a flat file structure,
00:01:20 however, your receiver system only accepts the data in a different structure, for example, in a
three-level hierarchy.
00:01:31 In the process flow of a scenario step, you are working in XML. You transform the data in the
XML message into an XML representation
00:01:43 of what the receiver or caller expects. When you create a scenario step, a transformation atom
called atom0
00:01:53 or final transformation atom is automatically provided for you. The transformation atom has a
preconfigured XSL file.
00:02:06 It is attached. XSL is a stylesheet language for XML documents.
00:02:16 You can use XSL transformation statements to convert an XML file into another format,
such as for example HTML.
00:02:27 In the integration framework, however, we use XSL transformation statements to transform the
XML message being processed.
00:02:37 When you define a scenario, you add your data transformation statements to the atom XSL
file. In synchronous scenarios, this is the response message
00:02:50 the integration framework returns to the original sender or caller. In asynchronous scenarios,
this is the message
00:03:00 the integration framework hands over to the outbound adapter before it is sent to the receiver
system or systems.
00:03:10 At runtime, the XSL transformation adds an extra payload section to the XML message –
payload type R, for receiver.
00:03:22 You can also add more transformation atoms anywhere in the step process to enrich the XML
message further during step processing.
00:03:37 XSLT is a language for transforming an XML document from one format to another. The
transformation statements are written as template rules.
00:03:50 When writing your transformation rules with XSLT, you can also use XPath and XQuery.
These three languages are closely intertwined.
00:04:03 XPath, or XML Path Language, uses path expressions to navigate through an XML document.
In the integration framework, you use XPath expressions
00:04:16 to navigate to XML elements in the message, such as a specific field in the sender payload
section.
00:04:25 XQuery, or XML Query Language, allows you to perform queries on the XML data in the
message. We are not using XQuery in the integration framework.
00:04:39 If you want to have further information, the links to tutorials on XSLT, XPath and XQuery are
shown here. Let us look at an example of XSL transformation.
00:04:56 It is a very simple example: we will convert the sender payload XML into a receiver message.
The sender message has a structure with <Header> and <Lines> as nodes.

16
00:05:11 The receiver message has a different structure with a new element, and with other names, and
a flatter structure.
00:05:20 For the receiver XML, we first design a root tag called <RCVMsg> or receiver message. We
define two new elements, <AccountNo> for account number and <Name>,
00:05:35 and use the XSL transformation statement <xsl: value-of select= "/> to extract the values from
the sender message elements in these new elements.
00:05:49 We use an XPath expression called SNDMsg for sender message /Header/Field1 to navigate
to the <Field1> node in the sender XML message.
00:06:05 Note: XSL stylesheet elements can be written without end tags if the element is nested within
another element.
00:06:15 In the example, <xsl: value-of select= ""/> ends with a / and >, and there is no end tag because
the element is self-closing.
00:06:34 Next, we declare a variable called linecount and assign the count of the number of <Line>
nodes in the sender message to it.
00:06:46 The result is 2. We use an XPath expression to navigate to the <Line> node.
00:06:55 We define a new element <LineCount> and use the <xsl: value-of select= ""> to extract the
count from the variable
00:07:04 into the receiver XML using the count function. When using a variable, add a $ sign in front of
the variable name.
00:07:19 We use the xsl:if test statement to make sure there are <Line> nodes in the sender message.
Note that if you use the > character as greater than, you must use the annotation &gt.
00:07:39 Otherwise the XML parser will interpret this as an element tag and you will get an error. Then
we use the xsl:for-each statement to select and loop through the <Line> nodes
00:07:53 in the sender message using XPath to navigate to the <Line> node. For each <Line> element
in the sender message
00:08:02 we define an element called <RCVLine>. Within this element, we define new elements
<Quantity> and <Product>
00:08:11 and extract the value of each field from the <Line> element. We use a relative path here, ./, to
access the sender fields
00:08:22 since we have already navigated to the <Line> node before. Now let me come to an online
demo.
00:08:37 I open my integration framework for this. And I just want to show you what it looks like when
you are creating a new scenario step.
00:08:58 I click the plus and call it newstep, save it. And when I now click Processing,
00:09:14 you can see exactly what you have seen before in the presentation – that we have a final
transformation atom here generated automatically.
00:09:25 If I click this area, then an XML processor opens, and you can then go to this XML editor and
add your XSL statements here.
00:09:40 Always use the <xsl:template name="transform"> section. All the other sections belong to the
integration framework and you should not touch them.
00:09:51 Here you can also see the name and where it is stored in the BizStore, so here you have the
atom 0XSL.
00:10:03 Let me show you now our small example that we saw in the presentation.
00:10:24 I have here the final transformation atom, and you can see here what I added to get from the
sender message to the receiver message.
00:10:42 You see here that I used a variable $msg, which I would not use in an XML processor. I use it
here in the integration framework context.
00:10:58 It is defined in each XSL atom as the variable that represents the incoming sender message.
So, if I run a test here,
00:11:20 I see my incoming message. I see it here: sender message, <Header>, <Field1>, <Field2>,

17
00:11:32 <Lines>, <Line>, and so on and so forth. And if I click the next red arrow,
00:11:44 I see how this message has been transformed by the XSLT in the atom0. So if you want to see
it outside the context of the integration framework,
00:12:02 you can do that as well because under Tools, and Control Center, Development we have a
point here that says Execute Stylesheets.
00:12:18 I can go to the BizStore, to the design area,
00:12:28 select my transform, and here in atom1, I have defined everything
00:12:39 without the $message in front of the XPath statements And now I can also select an incoming
message
00:12:51 that is then being executed for this transformation. I submit it.
00:13:08 And if I click the outbound document, you see here the receiver message that we have already
seen in the presentation.
00:13:23 Just one word on the XSL documents. When you are working here, you probably do not have
a straight-forward approach
00:13:41 to enter all the different atoms. It can happen that you delete an atom from a process flow, and
if it is a transformation atom,
00:13:54 then we do not automatically delete the attached XSL document. This is because we do not
want to delete your developments.
00:14:06 However, if you are sure that you do not need these XSL documents that are no longer
attached to a transformation atom, we have here this function
00:14:17 that helps you to remove the XSL stylesheets that you no longer use, and they are removed
from the BizStore.
00:14:27 So let us go back to our presentation. Here is a summary of this unit:
00:14:43 The data in the XML message that the integration framework processes is transformed using
XSL statements, such as for example:
00:14:54 <xsl: value-of select= ""> for extracting the value from an element, <xsl:for-each select=""> for
navigating nodes in the XML message,
00:15:06 or <xsl:variable> for defining a variable. XPath expressions are used to navigate through the
sections and nodes in the XML message.
00:15:22 At runtime, a new section is created in the XML message in the section R with the transformed
data. This is the final unit for Week 1. Thank you for attending this week.
00:15:38 We hope that you enjoyed it. We wish you all the best for the weekly assignment. Next week
we want to show you how to build an integration scenario.

18
www.sap.com

© 2017 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or
for any purpose without the express permission of SAP SE or an SAP affiliate
company.
SAP and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE (or an
SAP affiliate company) in Germany and other countries. Please see
http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain
proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for
informational purposes only, without representation or warranty of any kind,
and SAP SE or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and
services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be
construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue
any course of business outlined in this document or any related presentation,
or to develop
or release any functionality mentioned therein. This document, or any related
presentation, and SAP SE’s or its affiliated companies’ strategy and possible
future developments, products, and/or platform directions and functionality
are all subject to change and may be changed by SAP SE or its affiliated
companies at any time
for any reason without notice. The information in this document is not a
commitment, promise, or legal obligation to deliver any material, code, or
functionality. All forward-looking statements are subject to various risks and
uncertainties that could cause actual results to differ materially from
expectations. Readers are cautioned not to place undue reliance on these
forward-looking statements, which speak only as of their dates, and they
should not be relied upon in making purchasing decisions.