SAP connector when synchronizing information

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Integrating external applications from Bizagi > SAP integration > SAP on-premises ECC or R/3 with BAPIs >

SAP connector when synchronizing information


In the following section, we will illustrate how to integrate Bizagi with SAP without the need of programming.

This integration is easily set up through the out-of-the-box feature in Bizagi called the SAP connector.


The example illustrated in this section, differs from the one shown at SAP integration example, mainly because: this example here creates a process which is started by the system itself (automatically and periodically), which in turn synchronizes customers in Bizagi as fetched from SAP (creates and updates records of master entities in Bizagi); while the previous example is meant to provide end users with a process that allows them to search for available flights and book one that suits their needs, which in turn commits a transaction in SAP.


Before moving on, make sure you have already installed the SAP.NET assemblies, as required by this type of integration.

For detailed information and requirements about the SAP connector, refer to SAP connector.


Example: Synchronizing customers

In this example, we will integrate the SAP R/3 (mySAP) Flight Module in a Bizagi process which requires no human intervention.

Our goal is to create a process in Bizagi in which triggers on a weekly basis, and populates or updates, the flight customers as available in SAP.

We model our Bizagi process and call it the Load SAP Customers process, as shown:




For this scenario and when modeling the process, it is important that we set the appropriate properties for the BPMN shapes that support an automatic and periodical execution.

Notice we are using a timer as a start event.

We set the periodicity determining when new cases will fire off:





Keep in mind that for a production environment, and especially when planning to synchronize a large amount of records, you will need to plan accordingly such configuration (for instance, scheduling the execution outside of the busy hours, preferably running this at non-working hours).


Similarly, for the service task to invoke the SAP BAPI, we set an asynchronous treatment and specify its retry parameters:





For more information on the flight module that comes installed in SAP for educational purposes, refer to



We have divided this example and exercise into 3 major steps:



In this step we basically illustrate how to identify which parameters are involved both to send, and to receive information from SAP (especially as a helpful guide for people who are not necessarily SAP experts).

We will look up everything relevant to the function in SAP we integrate, mainly through the options provided by SAP Logon.

It illustrates the design considerations of our Bizagi data model in this example as well.  


Configuration of the connection

We will illustrate how to configure the connection to your SAP system.

This step is only need once.


Configuration of the BAPI invocation

We will illustrate how to configure the invocation of the SAP BAPI from the Bizagi process.

In this example, we invoke the BAPI wrapper called BAPI_FLCUST_GETLIST.



Keep in mind that for the third step to work, you should have already installed the required SAP.NET assemblies, as described at SAP connector (otherwise, Bizagi Studio won't be able to connect to your SAP system).



We will need to explicitly identify first, the relevant needed information in order to use the BAPI_FLCUST_GETLIST BAPI in SAP (which information is strictly mandatory in its import, export and table parameters).

We use SAP Logon to browse the details of this BAPI.


Through the se37 command in SAP and in the function builder, we can look up the specific function modules definition (and by then clicking Display):




For this example, we will not be using filtering criteria to fetch flight customers from SAP. However and  for the simplicity of the example's test, we will be retrieving only the first 20 records by using the MAX_ROWS parameter:




To learn about the information returned by SAP, we look up the BAPISCUDAT data structure within the response Tables or Export parameters:




Double-clicking the BAPISCUDAT data structure shows us what are the data types defining the information of a flight customer in SAP:





To configure the input parameters of your SAP integration in Bizagi, you need to consider that information presented both in: Import and tables.

To configure the output parameters of your SAP integration in Bizagi, you need to consider that information presented both in: Export and tables.


Notice you can use the Test/Execute option to validate your results.

In our example, we will test the results by using MAX_ROWS = 20.




These are our first 20 results for available flight customers (shown for validation purposes later on):




Taking into consideration the objective of our Load SAP Customers process, plus the information involved in the integration with SAP, in this example we consider the following definitions in our data model:




Notice these important aspects:

1. For the sake of the simplicity of the example, we will not be taking all information from a SAP flight customer, but selectively use only their: ID, Name, Postal code, E-mail address, Phone and Street.

2. Information from SAP will be stored in an entity called Flight Customer which is of Bizagi's Master type. Note that this entity strictly needs to be a Master entity.

If you wish to store information into parameter type entity, then this approach and example should not be used and using Custom replication should be done instead.

3. Our process entity is called LoadSAPCustomers and since entities in Bizagi require at least one attribute, we will use a Synchronization date attribute, useful to store when the synchronization was executed.

4. In order to allow Bizagi to automatically update customers when these have been previously loaded (and avoid duplicate records), it is important to define business keys for our Flight Customer entity in Bizagi:




Configuration of the connection

Now we enter the connection details for the SAP connector in Bizagi.

To do this, go to the Expert view and locate the External systems module.

In the panel to its right, locate SAP under the Connectors item.


Include a new SAP connector configuration by right clicking on SAP and selecting New Configuration...:




Enter the details of your SAP system as described below:

App Server Host: The IP address or name of your Server hosting your SAP system.

Client: The number of the client accessing the SAP system.

Idle timeout: The timeout in seconds for idle connections.

By default, you may assign a value of 600.

Language: The 2-letter ISO code that represents the language setting (as inputted when accessing SAP through SAP Logon).

Peak connections limit: The maximum number of connections you will allow through the SAP connector.

By default, you may assign a value of 10 connections.

Pool size: The number of connections that will be handled for reuse.

By default, you may assign a value of 5.

System number: The number of your SAP system.

User: An authorized SAP user to access and invoke BAPIs or RFCs.

This SAP user configured here will be used as the service account of this connector.

User Password: The password for that authorized SAP user.



When done click OK.

Notice you may use different configuration parameters for each of your project environment (development, test and production).


Configuration of the BAPI invocation

We will integrate Bizagi with SAP in the service task we defined as asynchronous.

This means that at the Load Customers from SAP activity, we define an activity action at On Exit to invoke the BAPI wrapper called BAPI_FLCUST_GETLIST from the step 4 of the process wizard.

To do this, follow these steps:


1. Click at On Exit and add a SAP invocation.




2. Browse for that function module by typing the BAPIs name and using the Search button:




Select the BAPI and click Next.


3. Click on the Maximize button to zoom in the inputs configuration.

Make sure you use the Constant function to map a value of "20" into the MAX_ROWS parameter:




Click Next.


4. Map the outputs accordingly.

What is really important for this scenario is:

To make sure you are mapping the response from SAP that is the business key definition in our Bizagi data model (in this case CustomerID).

To make sure you map into Bizagi's Customer collection, by using the default Append configuration for records which is represented with an(A).





The use shown above  in which we map fields that belong to the business keys definitions in Bizagi Studio (in order to update existing records), will require that such records are already persisted in the database.

For instance, this will not work if such information is being handled directly on user interfaces (while residing only in the current scope of the activity).


Click Next.


5. Click Finish to bypass the Error handling configuration and complete the configuration.

This is done because this specific SAP BAPI does not have any functional exceptions predefined, and therefore, no special error handling is needed for this scenario.



To learn about configuring error handle for SAP integration (when BAPIs have predefined functional exceptions), refer to SAP exceptions configuration.


Once this is finished, you will see the Connector BAPI_FLCUST_GETLIST being set.

At this point, it is also important to note that because this is an automatic process with no human intervention, it is necessary to make sure that our process entity is initialized.


6. Initialize the process entity by creating a new activity action at On Enter:




For this example, we create an expression that has an assignment setting the current date to our Synchronization date attribute to record when it was executed:




In the end, this is how business rules at our only task should be listed:




And that's it!

At this point we have integrated Bizagi with SAP through the SAP connector (which avoids the need of programming), and we will fetch and synchronize information from SAP directly and in a scheduled manner into Bizagi.



Given the nature of this scenario in which we want the system by itself to run the synchronization periodically, this example is run by the Scheduler service of your Bizagi project and therefore it will fire up once the Scheduler is started and the predefined periodicity is met.

Recall you may manage the Scheduler service (to start or restart it) by using Bizagi Management Console:




Once a new case has run, verifying the synchronization of information can be done by using Bizagi Studio's Entities module to load the values of our Flight Customer entity. You should be able to see the 20 first records of flight customers in SAP:





To verify for an update or further executions, you will possibly need to reconfigure the invocation of the BAPI so that you: fetch a larger number of records from SAP (e.g, MAX_ROWS=50), while ensuring that information on some customers have changed in SAP (possibly use BAPI_FLCUST_CHANGE).

In addition to the above, you may include a regular start event (as a temporary modification in the process) so that you can manually create new cases in the Work portal, only for verification/testing purposes: