Home | About | Downloads | Arduino | Documentation | Examples | News

Ich willige bis auf Widerruf ein, die Übermittlung von Newsletter an diese E-Mail Adresse.


PROCE55® Integration

Today, in the interconnected world people need information to get knowledge and act anytime and anywhere. This can be accomplished by mobile application based on PROCE55® Mobile which is integrated with the back-end services and data. In fact, you can abstract the world information system as consisting of two main components:

>  Back End Super System or Internet which evolves to a universal information and transaction system of cloud based resources (with data and transaction integration with the Enterprise Information systems)
>  Front End Clients (particularly Mobile Devices) which allow for data access and data modifications as well as for transaction control in context of the above mentioned Back End Super System

If you want to access the data associated with the Internet resources and central databases you can use the APIs and access them using the Representational State Transfer (REST) protocol.

If you want to process the transactions in context of the back-end servers (e.g. Enterprise Information Systems) the Simple Object Access Protocol (SOAP) protocol can be used.

PROCE55® Mobile is equipped with the enhanced integration capabilities according to the principles of the Service Oriented Architecture (SOA) and Web services (WS) using both REST as well as SOAP approach.


A Web API is an application programming interface (API) which can be used by a Web Client to consume Web Services exposed from a back-end system (server-side Web API). A server-side web API is a programmatic interface consisting of one or more publicly exposed endpoints to a defined request–response message system, typically expressed in JSON or XML, which is exposed via the web - most commonly by means of an HTTP-based web server.

An example with all the technical details [PDF]  |  [PROCE55 Modeler app file]


REST is optimal when you are exposing a public API over the internet to handle create, read, update, and delete (CRUD) operations on data. REST is very simple, it uses standard HTTP (GET or POST) and it permits various data formats. The Internet is full of resources, you can access the data associated with them using APIs. Typically REST accesses the named resources through the associated URI using the HTTP GET with a query string or HTTP POST with the XML data in the body of the request. The response contains the data in different formats (e.g. JSON, XML as well as non-standard proprietary data formats).


SOAP focuses on exposing pieces of application logic (not data but operations on data, e.g. ACID transactions) as services using the HTTP POST method. It ensures security, data integrity, and data privacy but it is more complicated than REST and it has also more overhead information (SOAP envelope). The XML Namespaces and XML Schema definition (WSDL definitions) are usually used for SOAP specifications. To build the interoperable clients and servers based on SOAP can be a complex problem for many people, but you cannot avoid using the SOAP approach if you want to implement more complex integration scenarios (integration of applications and processes). Naturally, you can use WSDL and SOAP for integration in context of PROCE55® Mobile, if you prefer this approach, but we are providing you with a simple and robust alternative method.

In our large and complex application integration projects we have learned that people involved in integration of applications usually know how to create the XML request, how to transfer it using HTTP POST (i.e. how to process a Web service call) and how to parse the returned XML response. Therefore we have developed a pragmatic approach to process the transactions in context of the back-end servers which is called XML_HTTP.

SOAP-based integration example with server code [PDF]  |  [Sample server source code]


XML_HTTP is a communication protocol for executing functions (Web services) in a remote system. It uses XML to encode its calls and http(s) as a transport mechanism. XML_HTTP can control the processing of the transactions in any back-end system. Any piece of the application logic of the back-end system can be exposed as a Web service. XML_HTTP is based on the SOAP approach but it simplifies the data formats (request and response) and eliminates the overhead information. It is optimal for processing of the transactions synchronously which is typical for communication of a mobile application with the back-end systems. The asynchronous processing is also possible using queue principles. For exposing of XML_HTTP services a simple Application Server (AS) can be used. You can create the Application Servers for exposing of any application logic implemented in any programming language. This Application Server can also enable the access to the standard as well as legacy Enterprise Information Systems and Applications.

Last but not least, all of our PROCE55® Connectors (including the PROCE55® SAP Connector XPCo) are using the XML_HTTP protocol for communication. These Connectors allows you to connect the professional Enterprise Information Systems and Enterprise Resource Planning Systems (ERP like SAP®).

How to Integrate Backend Systems Using XML_HTTP

If you want to use the XML_HTTP protocol you do not take care about the communication between the mobile application and the back end server, you have to understand the interface for the service call only.

If you want to integrate your process which is controlled by your mobile application with the back end system you have to define the interface of the service call in context of the back end system.

The interface for the service call defines the following:

>  URI of the Application Server which implements the services (or connects the back end servers)
>  Function Name which identifies the service
>  Input parameters (scalars and tables)
>  Return parameters (scalars and tables)

The corresponding service call is performed in run time using the http(s) POST method synchronously.
The communication scheme shows the following picture:

An example of a simple application server:
This server can be implemented as e.g. node.js based service or similar, in any other programming language. You can find the sample coding in Perl language below.

XML_HTTP Request Example:

Here is the above example in text format (real format): <XML_HTTP_REQUEST> <FUNCTION NAME="FUNCTION1"> <INPUT> <URL VALUE="https://www.proce55.com/cgi-bin/AS/svr.pl" /> <REQUESTENCODING VALUE="UTF-8" /> <RESPONSEENCODING VALUE="UTF-8" /> <PARAMETER1 VALUE="value of parameter1" /> <PARAMETER2 VALUE="value of parameter2" /> </INPUT> <TABLES> <FIELDS TABLE="TABLE1" FIELD="FIELD11" ROW="1" VALUE="value 111" /> <FIELDS TABLE="TABLE1" FIELD="FIELD11" ROW="2" VALUE="value 112" /> <FIELDS TABLE="TABLE2" FIELD="FIELD21" ROW="1" VALUE="value 221" /> <FIELDS TABLE="TABLE2" FIELD="FIELD22" ROW="1" VALUE="value 222" /> </TABLES> </FUNCTION> </XML_HTTP_REQUEST> Remarks:

  • please note that in the real Request there are some additional standard parameters (URL, REQUESTENCODING, RESPONSEENCODING), which have been removed from the picture above, to simplify it
  • in general, the order of the parameters in XML format is not guaranteed

    How to define the service interface of the above XML_HTTP Request:

    How to define the above input parameters (tables and scalars):

    Example of the XML_HTTP Response:

    Here is the above example in text format: <XML_HTTP> <XML_HTTP_RESPONSE> <RETURN_PARAMETERS> <RETURNPARAMETER1>retvalue1</RETURNPARAMETER1> <RETURNPARAMETER2>retvalue2</RETURNPARAMETER2> </RETURN_PARAMETERS> <TABLES> <TABLE1> <FIELD11>value 111</FIELD11> <FIELD12>value 112</FIELD12> </TABLE1> <TABLE1> <FIELD11>value 121</FIELD11> <FIELD12>value 122</FIELD12> </TABLE1> <TABLE2> <FIELD21>value 211</FIELD21> <FIELD22>value 212</FIELD22> <FIELD23>value 213</FIELD23> </TABLE2> </TABLES> </XML_HTTP_RESPONSE> </XML_HTTP>
    How to define the service interface of the above XML_HTTP Response:

    How to define the above return parameters (tables and scalars):

    Application Server on the back end system

    The Application Server exposes the application logic from a server application. The server application resides on the back end server. The Application Server exposes the application logic as set of functions which can be called from the PROCE55® Mobile Client Application using the XML_HTTP protocol (synchronous exchange of XML_HTTP requests and responses). Any programming language can be used for implementing of the Application Server. The Application Server can also wrap the application logic of some other legacy and/or standard application installed on the back end server (e.g. SAP® system) and make it available for the mobile application. The Application Server can also implement the needed authentication and authorization logic.

    From the technical standpoint The Application Server can be implemented as:

    sockets-based program
    Common Gateway Interface (CGI) program or script in context of any http server

    Example of an Application Server

    If you want to create simple Application Server the following example can help you to understand its principle.

    Here is an example code of a simple Application Server implemented as Perl based CGI script in context of Apache web server. This code has been used in the above examples of XML_HTTP Request and XML_HTTP Response.

    The following text shall be saved as a Perl file: svr.pl

    This file svr.pl can be put into the directory:

    of the Apache http server on Linux (we are using the Amazon Linux - AMI).
    Do not forget to apply chmod 755 on the file #!/usr/bin/perl -w use CGI qw/:standard/; use XML::Simple; &main(); sub main { my $request; my $response; # buffering off select(STDIN); $| = 1; select(STDOUT); $| = 1; # receive the request (transferred using http POST) if ( $ENV{ REQUEST_METHOD } eq 'POST' ) { read( STDIN, $request, $ENV{ 'CONTENT_LENGTH' }, 0 ); } # ... INSERT YOUR APPLICATION LOGIC HERE ... # parse the XML data from the request and prepare the response accordingly # start of example: my $xml_ref = eval{ XMLin( $request ) }; my $function; my $par_ref; my $par; my $val; my %input_pars; if ( $xml_ref ) { # extract function name $function = $xml_ref->{'FUNCTION'}->{'NAME'}; if ( $function eq 'FUNCTION1' ) { # extract input parameters $par_ref = $xml_ref->{'FUNCTION'}->{'INPUT'}; foreach $par ( keys %$par_ref ) { $val = $par_ref->{ "$par" }->{'VALUE'}; $input_pars{ "$par" } = $val; } # ... process input parameters and create response ... # in this example the test response will be used: $response = $test_response; } } # end of example # send the response print STDOUT "Content-Type: text/xml; charset=utf-8 \r\n\r\n"; print STDOUT "$response\r\n"; return 1; } # this is an example of a hard-coded response for testing: my $test_response = <<END_OF_TEST_RESPONSE; <XML_HTTP> <XML_HTTP_RESPONSE> <RETURN_PARAMETERS> <RETURNPARAMETER1>retvalue1</RETURNPARAMETER1> <RETURNPARAMETER2>retvalue2</RETURNPARAMETER2> </RETURN_PARAMETERS> <TABLES> <TABLE1> <FIELD11>value 111</FIELD11> <FIELD12>value 112</FIELD12> </TABLE1> <TABLE1> <FIELD11>value 121</FIELD11> <FIELD12>value 122</FIELD12> </TABLE1> <TABLE2> <FIELD21>value 211</FIELD21> <FIELD22>value 212</FIELD22> <FIELD23>value 213</FIELD23> </TABLE2> </TABLES> </XML_HTTP_RESPONSE> </XML_HTTP> END_OF_TEST_RESPONSE
    SAP® Integration

    PROCE55® SAP® Connector - XPCo

    Our PROCE55® ® Connector XPCo enables the seamless integration with the standard ERP system SAP®. It is the component of the PROCE55® suite which integrates the PROCE55® BPM engine or PROCE55® Mobile with the SAP® system(s). It is a maintenance-free message converter which connects the PROCE55® Processor with the SAP® system at run time and allows for data extraction and/or control of the transactions using BAPIs/RFMs. XPCo uses for SAP® integration the SAP® RFCSDK (RFC Library). EastGate developed the XPCo SAP® Connector based on Linux operating system, because of its stability and security.

    XPCo follows the principle of the loose coupled systems and allows for the integration at the run time (late binding). In the design time of the application development there is only the definition of the interface of the SAP® Remote Function Module (RFM) needed to be inserted into the process model.

    XPCo is a message converter only, it converts ingoing XML message to a remote function call in context of the SAP® system using the SAP® Gateway and converts the returned data into the XML message according to the XML_HTTP communication scheme. This simple architecture implies the high availability of XPCo. XPCo is also maintenance free, after the initial configuration of the SAP® systems which have to be connected, there is no need to maintain it.

    The example of use of the XPCo for integration of PROCE55® Mobile with SAP® shows the following picture:

    If you want to use our advanced integration technologies including the SAP® connectivity please contact us using mobile(at)east-gate.eu

    Here is one real example of integration of PROCE55® Mobile with SAP®. This example shows a typical process – Create Notification of Failure of Machine - in context of the SAP® module Plant Maintenance (PM). This process has been implemented using the above mentioned components of PROCE55® suite:


    PROCE55® Mobile is the evolutionary extension of the standard PROCE55® technology from East Gate® which allows for process control from anywhere and at any time.

    With the PROCE55® Mobile from East Gate® you can design and deploy your professional mobile applications easily and in extremely short time.




    What Is It?

    Quick Start






    Legal Notice (Impressum)






    GTC (AGB)

    Datenschutzerklärung (DSVGO)


    e-mail us your questions:





      © 2015-2017 East Gate GmbH, www.east-gate.eu