Topic overview

From Comarch ERP Enterprise 4, the Business Integration Service (BIS) is also available for remote call-ups. This covers the data import and data export functionalities of the BIS as well as a search function, which together are referred to as remote BIS. The data import and data export offer a similar functionality as the file-based BIS. The search function works analogous to the value assistants and locator searches of the ERP system’s graphical user interface. The respective data is transferred directly through the network and not via the Knowledge Store as it is the case with the file-based BIS.

From Comarch ERP Enterprise 4, the remote BIS interfaces are available using CORBA as communication interface. In order to use the remote BIS interfaces via CORBA, knowledge of the CORBA interface of the ERP system is necessary.

From Comarch ERP Enterprise 4.2, the remote BIS interfaces are also available using web services as communication interface. In order to use the remote BIS interfaces via web services, knowledge of the web services interface of the ERP system is necessary.

Target group

• Application developers
• Technical consultants

Description

The functionality of the remote BIS interfaces is realized in the ERP system by means of background applications that are called up remotely. Thus, they are independent of the concrete communication interface.

Functionality and data formats

The data format of import data, export data, and search results is XML. UTF-8 is used as encoding. Consequently, a client generally needs to employ an XML parser in order to be able to make use of the data and to generate XML documents.

When applying CORBA, the transfer is carried out in blocks with each block requiring a separate call-up of the background application. In import and export, the blocks put together add up to the complete XML document. The XLM documents for import and export can become very large. As the data transferred in a call-up through CORBA has to be stored temporarily in the main memory of the server (and that of the client as well), the XML documents are not transferred as a whole but in blocks.

If web services are used for import or export, the data is transferred in one block because web services use a stateless protocol which does not allow for transfer in several blocks. In case of large volumes of data, this can put a heavy load on the application server and cause considerable performance losses. Thus, the web services interface is not suited to transport large data quantities.

Regarding import and export, the format of the XML document is the same as with the file-based BIS and, thus, corresponds to the XML scheme provided by the BIS. Other data formats such as CSV are not available when using the remote BIS. A further restriction of the remote BIS is that attributes of the BLOB category cannot be transferred.

With regard to the search function, the search results are transferred page by page when using CORBA; that means every page constitutes a separate block that contains a certain number of complete records. Each page of a search result is an individual XML document; it can therefore and in contrast to the result of an export process be parsed separately. For the exact format in which search results are returned, see Data format of search results.

In case of web services, the search results are not transferred in blocks since the protocol used is a stateless one.

Furthermore, the search function provides an existence check which returns a single record. Purpose of this interface is to enable the simple query of whether at least one record exists that matches a certain search. If there is such a record, its attributes are not returned as XML document but as values in a parameter list. In this way, remote verification of external keys can be realized easily.

Common features

The interfaces for CORBA and web services are described in discrete articles – CORBA Interface and Web Services Interface respectively. The present chapter deals with those parts of the interfaces that are common to both communication channels.

Data format of search results

The following example is used to describe the format of the XML documents representing the result pages of the remote search interface:

<?xml version="1.0" encoding="UTF-8"?>
<semiramis>
  <SearchResultRow>
   <guid>004076BF35F71E1080568464962B0000</guid>
   <name>Dr.</name>
   <deleteTime>
     <date>16/12/2003</date>
     <timeOfDay>17:50:58.304</timeOfDay>
   </deleteTime>
  </SearchResultRow>
</semiramis>

The example shows a result page with one row. This row is the element SearchResultRow. Further result rows would follow this element directly. The elements below SearchResultRow represent the result columns. The names of the elements are the attribute names from the OQL search (guid, name); the values of the elements are the attribute values. The format of an attribute value depends on the respective attribute’s data type and is described in the next chapter.

Attributes of certain data types are presented in a complex manner, i.e. their XML element in the XML document consists of one or several sub-elements. That is the case if the overview in the next chapter shows that the return value of the data type consists of columns. An example in the above XML document is the attribute deleteTime.

Which result columns are given in each row depends on the OQL search used. In general, it is advisable to create a particular OQL search for a search that is to be called up remotely.

Data types for searches

The data types listed below are supported for restricting and return parameters. For both cases, it can be defined whether a user-specific or a technical format is to be applied. For the user-specific format, sample strings are given; the concrete strings depend on the user settings. The technical format is always independent of the user settings.

Concerning the complex data types that are listed as not supported, there is always the option to define the search in such a way that the separate attributes (e.g. the amount of the foreign currency) can be used as restricting or return parameters. Only the direct using of the complex type may not be supported.