Large software systems consist normally of various components. This serves, among other things, to reduce the complexity of individual components, distribute the load, make efficient use of limited resources and, last but not least, enhance expandability. A requirement frequently arising in the context of the expandability is the integration of an existing software system with a new component or even another software system. The subject-related questions are to a great extent independent of the specific software system, the selected platform or programming language. In a specific integration use case, it is also necessary to choose the appropriate interface technology and architecture for specific overall conditions.

This article is to help make the right decision. The first part lists the various aspects that are important in integrating software systems and describes their impact on factors such as performance, response times, resource consumption, etc. The second part describes detailed possibilities for the integration of a software system, including primarily the specifics of integration with Comarch ERP Enterprise.

This article intends also to show that there is not – and cannot be – “one” interface technology that meets all requirements equally well. The correct choice depends on the specific use case and the overall conditions. The best solution can nevertheless be either exchanging of a file in the data system or calling a Web service through the Internet.

The integration content-related issues, such as which services, data structures and data an interface must provide, are not part of this article and are irrelevant of the choice of the interface technology.

Client and server

When processes in software systems take place in a distributed manner, one component assumes the role of a client that makes requests and another component assumes the role of a server that answers the requests. In general, there is a network between client and server, which transmits requests with a specific protocol and encoding. In some cases, the roles of client and server may change during communication or over time. For example, Comarch ERP Enterprise Application Server acts as the server for a browser client, but it also acts as a client to a database server. The component that makes a request is hereinafter always referred to as the client.

Since the server usually has to be able to support more than one client at the same time, it needs to manage the logged-in clients and, if necessary, it needs several executive units to answer incoming requests.

Quality of software systems

When extending a software system, it is necessary to ensure that the extension itself has the appropriate quality, but also that the effects on the existing software system do not impair its quality. The following quality characteristics, among others, must be taken into account when implementing client and server:

• Throughput – most software systems are transaction-oriented. The throughput describes the number of transactions at a given time.
• Response time – this time should not exceed a certain level (approx. 0,5-2 seconds) especially in interactive systems where users expect direct responses to their input. Note that high throughput does not represent low response time and vice versa.
• Resource consumption – resources are, for example, computers, main memory, hard disk capacity, network cards, network connections, processors, threads. The amount of resources in a software system is limited. To be able to process quickly as many requests as possible, a request should use as few resources as possible and the requested resources should be released again as quickly as possible. Shared resources must be protected by locking mechanisms. This can impair throughput.
• Scalability – a system should grow with an increasing number of clients and, thus, increase throughput without impacting the response time.

This is achieved in particular by minimizing network communication through caching (database cache, server cache, client cache) and by parallelizing tasks within a request.

• Portability – to be able to use other, more powerful hardware if required, the extension should be portable. This is influenced by the following factors:
  • the programming language
  • the operating system platform that determines the syntax for path specifications, for example
  • the DBMS used, because despite the standardization of SQL, different DBMSs use different syntax and offer different data types the communication protocol between client and server
• Availability – if an extension is to be installed multiple times, it is necessary to ensure that fixes and new features emerging during maintenance and further development can be passed on in a controlled manner and installed with as little downtime as possible.
• Security – to ensure system availability and to protect its data from unauthorized access, it must be able to protect itself against unauthorized requests. There are various ways to achieve this with authentication and authorization mechanisms. Extensions should not bypass the security mechanisms of the existing software system.
• Testability – extensions to a system should be as easily testable as possible in order to check they work properly and to be able to investigate problems.

Infrastructure usage

When an extension to a software system is created, it must integrate suitably into the infrastructure of the existing system. This means on the one hand that existing services such as caching, locking, authorizations etc. should be used in order to save resources and to minimize the administration effort, and on the other hand, that in places where these services are not used intentionally or obligatorily, no conflicts or errors occur as a result.

Exemplary services to be taken into account:

• browser cache
• shared cache on Comarch ERP Enterprise Application Server
• page cache on the database server

Blockades:

• semaphores in Java (synchronized usage)
• business object locks and logical locks in Comarch ERP Enterprise
• table, page and row locks on the database

Authorizations:

• client certificates
• Comarch ERP Enterprise authorization and authorization roles
• object- and DBMS users-related database authorizations

Network

When connecting to a remote interface, every request from a client is transmitted over the network. As the number of clients grows, so does the influence of the network. The following properties are characteristic for a network:

• Block size – networks send data in individual blocks by default. In the case of TCI/IP, these blocks are called packets and can transfer user data up to the default size of 4 kilobytes.
• Network bandwidth – this is the amount of information that can be transmitted simultaneously over one network connection.
• Latency – the ISO-OSI network infrastructure defines different transport layers of the ISO-OSI. Each transition to another layer and each request travel, e.g., a TCI/IP packet travel from one router to another, costs time.
• Topology – the number of nodes and their interconnections affect the path of a packet from source to destination.

This has the following consequences:
1. Each request can be answered at most as quickly as the latency permits. This cannot be changed, regardless of the size of the bandwidth.
2. The transmission time of a data volume that fits into the payload of a single packet is determined practically exclusively by the latency. It is therefore counterproductive to transmit data in blocks smaller than this size.
3. Increasing the bandwidth helps minimize the transmission time of large interrelated data volumes. When large amounts of data are transmitted, they should be transmitted in blocks to take advantage of the bandwidth.

Protocol

To communicate over the network, client and server use a protocol. It defines how a connection can be established, a request sent, a response received and a connection terminated. Furthermore, a protocol also defines which error states can occur and how they should be handled. The following properties of the protocol are particularly relevant:

• Stateful or stateless protocol
  Does the server store one state per client or is each request interpreted as a new request from any client?
• Encrypted or unencrypted protocol
  Do client and server create an encryption of the connection or is the data transmitted unencrypted?

Stateful protocols know the principle of a fixed connection, similar to a telephone connection between two participants. The connection is established once, the participants are also identified only once, and all further requests transmit only user data. The cost-intensive steps are therefore performed only once. A prominent protocol from this category is the protocol used by the Object Request Broker in the case of CORBA for communication over TCP/IP.

The most popular stateless protocol is HTTP (Hypertext Transfer Protocol). In this protocol, a request with parameters is sent to an address, and the server responds by sending an HTML page. Since the server does not know the client or the client’s user, it cannot recognize consecutive requests as related. This is not a problem for simple web pages, but it is not sufficient for complex processes.

Processes such as online banking or the operation of Comarch ERP Enterprise or the export of large amounts of data require that states are stored for each client. If a stateful protocol cannot be used for technical reasons, the existence of such a protocol must be simulated. This requires more logic on both the client and server side. If a client does not have this logic and cannot be extended, this must be compensated for by, for example, re-authentication with each request.

In very simple cases and provided that the client has an appropriate logic (e.g., cookies in the case of a web browser client), the state can be stored on the client itself and sent as a parameter with each request. In this being the case, the server is stateless and resources are only stored for the duration of the processing of a request. In more complex cases, the state must be stored on the server. In this case, the client usually only stores and sends a “session identification” that was assigned by the server after initial authentication.

Requests

Client requests can be described with the following properties:

• Number of clients
  How many clients do make requests simultaneously?
• Request frequency
  How many requests does a client make in a given time?
• Expected response time
  Does a response have to be available quickly?
• Data volume
  What amount of data is sent with the request and what amount of data is expected back in response?
• Data format
  Is the data encoded in binary or text format?
  Is the data structure proprietary or standardized?
  Is the data encrypted in the request itself?
• Read or write access
  Does the client only want to query data or modify it as well? How up-to-date does the read data need to be?
• Synchronous or asynchronous connection
  How much of the response does the client expect immediately?
• Active connection or polling
  Does the client send a specific request at all or periodically check for the presence of certain data at a defined location?
• Stateful or stateful connection
  Does the server maintain a state across multiple requests?

All these issues should be clarified before designing or selecting an interface, since they have quite a significant impact on the design. The consequences of the respective properties are listed below.

Number of clients

For stateful servers, each logged-in client represents a reserved amount of main memory on the server for the duration of the logon.
This memory is rarely required and is stored for a relatively long time. For stateless servers, the amount of memory per request is dominant and usually higher than for a request to a stateful server. If the transfer of the response to the client cannot be split over multiple calls, this can temporarily allocate a potentially large amount of main memory.

Request frequency

If a large number of requests are expected at a given period and the server logic accepts it, then several executive units on the server should process the client requests simultaneously in order to achieve the necessary throughput.

Expected response time

To minimize the impact of network latency, client requests should be bundled (i.e., sent in blocks). Only then is it possible to use the available network bandwidth.

Data volume

In the case of a request, only the data that is actually needed should be sent and requested. In the case of SQL access to the database, for example, the number of columns and rows in the result should be as small as possible.

Data format

The use of binary data formats reduces the amount of data to be transferred and is preferable to high-volume data transfers. The extent to which binary data can be correctly interpreted on diverse platforms depends also on other factors. For example, CORBA offers a binary format that is compatible with various platforms and is converted to the platform specifics (byte order: little or big endian, encoding of characters) by the ORB intermediate layer if necessary.

The use of text formats is useful for small amounts of data and if the clients and servers involved use only little logic or also strongly different technologies (e.g., C++ server and Perl client). In general, the use of text formats represents an increase in the volume of data to be transferred for the same amount of user data. Depending on the format, this is between 1.5-4 (Base64 encoding, hex encoding) to 10-15 (XML with start, end and meta tags). In some cases, the increased data volume can be compensated for by compression. However, an issue to be addressed is whether the resulting increased computing and hardware effort is justified.

The use of proprietary data structures can be useful for closed systems in which client and server are from the same source. In the event of changes to the requirements, it is then possible to react more quickly and appropriately. When communicating beyond one’s own system, the use of standardized formats (e.g., EDI) is generally appropriate.

When communicating beyond one’s own system, the encryption of data is relevant if the data is to be transmitted over insecure channels, e.g., over the Internet via HTTP protocol or as an e-mail. The procedures used here again require additional logic and metadata for encryption on the client and the server.

Read or write access

Read access generally requires fewer resources than write access. If, in addition, the result of a read access does not have to be 100% up-to-date, the lock request can be dispensed with and data can be returned from a cache.

Synchronous or asynchronous communication

In a synchronous communication, the client expects an immediate response from the server. This is the normal case, since at least the confirmation that the request has been accepted by the server should be taken into account. If the actual response is not needed or is not needed until a later time, the server has the option of waiting for resources to become available.

Active communication or polling

When the client actively calls the server, the client and server must communicate synchronously at least part of the time. The advantage is that the server only provides data when the client expects it. With polling, the client periodically checks whether data, e.g., in the form of a file, is available at a location that can be accessed by both sides without making a prior request to the server. Polling is suitable for the transmission of large amounts of data, which can be delivered by the server without additional input parameters. Errors on the client are not normally reported back to the server. It is also possible to combine the variants “active call” and “polling”. In this case, the client first sends a request to the server and only then starts polling.

Stateless or stateful connection

When using stateless calls, authentication must be performed for each request, which has a negative impact, especially when the request frequency is high. In addition, with stateless calls, complex processes must always be packed into a single request and the entire result sent in one response. This leads to less modular interfaces. Since requests and responses must usually be entirely stored in the main memory, at least temporarily, for processing of a request, this type of call is also not suitable for transmitting mass data. With stateful calls, the overhead of authentication occurs only once, complex calls can be split into reusable parts, and the input parameters as well as the result of the request can be transmitted in several blocks.

Interface technologies

This section describes interface technologies that can be used to integrate software systems. The level of support that Comarch ERP Enterprise normally offers within this scope is also discussed.

A concrete solution to an integration problem will generally be based on a combination of several of these technologies, as shown in some examples.

Files

When data is transferred in the form of files, the data is made available at a central location to which the server has write access and the client at least read access.

Files are also well suited for large amounts of data. An example of the use of files for data exchange between different systems is BIS. With the BIS, data can be imported or exported automatically.

One of the disadvantages of files is the lack of transactions. When a file becomes visible or accessible to another process and what content is read depends largely on the operating system.

Comarch ERP Enterprise supports the file system of the application server and the Knowledge Store.

File system of the application server

Comarch ERP Enterprise can access the file system of the application server. Depending on the configuration of the operating system, both the local file system and remote file systems (“network drives”) are available here.

Files are accessed via their file path. Note that file paths depend on the computer and its operating system and therefore may not be used across application servers. One way to regain this independence is to use file paths relative to the “semiramis/usr” folder. The file path to the “semiramis” folder can be accessed on each Comarch ERP Enterprise Application Server in the respective notation. Corresponding variables (“{semiramis}”) are already available for this purpose in the BIS, during the output and reorganization of documents.

Knowledge Store

The Knowledge Store provides a database-supported file system. Its file paths are valid across application servers and are independent of the operating system.

Third-party software can access the Knowledge Store via WebDAV over https protocol. This enables access directly from client computers that do not have access to the application server’s file system. Since WebDAV is a relatively new standard, this type of access is not yet offered by all operating systems and applications. Authentication is performed with a certificate or password.

More information can be found in article: Knowledge Store.

Databases

SQL (direct access)

Direct access to databases is possible from Java via the JDBC interface, for instance, whereby a JDBC driver must be used for the respective database. Access to the database may depend on the DBMS despite the use of JDBC.

Access to external databases

External databases can also be accessed from within Comarch ERP Enterprise. The standard JDBC interface of the JDK can be used for this purpose, for instance.

Access do Comarch ERP Enterprise database

Technically, it is also possible to access Comarch ERP Enterprise databases directly. However, this is not recommended for the following reasons:

• The mapping of Comarch ERP Enterprise Business Objects and the respective data types is DBMS-specific and their form is not guaranteed by Comarch ERP Enterprise Software AG.
• DBMS provides a technical data model in which GUIDs are binary data, and timestamps are stored in a compact format that no DBMS can evaluate directly.
• Read access bypasses Comarch ERP Enterprise caching. This reduces the speed of the access.
• Write access bypasses Comarch ERP Enterprise caching and locking. This way, the potentially inconsistent data is read.
• There are no authorization checks, except for the means of the DBMS.

Instead, Comarch ERP Enterprise ODBC or the Comarch ERP Enterprise Persistence Service should be used.

Comarch ERP Enterprise ODBC

Comarch ERP Enterprise ODBC allows access to Comarch ERP Enterprise databases via an ODBC interface integrated in Comarch ERP Enterprise, which can be used by third-party software. Access is independent of the DBMS of the Comarch ERP Enterprise databases.

With Comarch ERP Enterprise ODBC, note that only read access to the databases is possible. Technically, access requires the use of HTTPS protocol.

Comarch ERP Enterprise ODBC provides a database schema enriched on the basis of Comarch ERP Enterprise metadata. It includes business keys from relationships and the natural language description of valueset values as virtual attributes. Furthermore, virtual tables for accessing the Knowledge Store and dynamic objects are included. You can also access your own additional data and calculations in the form of virtual tables and virtual functions. A translatable description is available for each attribute in the database schema.

Business entity level permissions are evaluated when accessing Comarch ERP Enterprise ODBC.

More information can be found in article: Knowledge Store.

Comarch ERP Enterprise persistence

The Comarch ERP Enterprise persistence service can only be used within Comarch ERP Enterprise. However, remote access is feasible with an intermediate layer.
For example, in Comarch ERP Enterprise, a background application can be created and then called externally via CORBA or Web services. Because they are independent of the calling channel, background applications are an investment-safe alternative, since programmers do not have to deal with the specifics and version dependencies of a particular channel.

The Comarch ERP Enterprise persistence service is independent of the DBMS. It allows read and write access and the use of Comarch ERP Enterprise caching, locking and optionally permissions. It supports both object-based and tuple-based access, as well as single and bulk operations. It can be used to implement a very simple background applications, e.g., executing a single database access using Comarch ERP Enterprise OQL, as well as any complex logics. By using already existing logic classes, a high degree of functional reuse can also be achieved.

More information can be found in article: Persistence Service.

Remote connection

Remote calls are used to synchronously execute certain actions on a remote system. A certain protocol is used for connection.

COBRA

CORBA is a protocol for remote connections that can be used on diverse platforms. CORBA can handle stateful calls and is therefore suitable for the transfer of mass data.

Comarch ERP Enterprise as a CORBA server

Comarch ERP Enterprise contains a CORBA server. The data format of the interface, to which the clients must adhere, is defined in an IDL file.

The CORBA interface can be used to invoke any background applications that run in Comarch ERP Enterprise. In addition, the BIS (data exchange) functionality is available.

When the clients log on to the CORBA server, authentication takes place and the authorizations in Comarch ERP Enterprise are verified.

More information can be found in article: COBRA Interface.

Comarch ERP Enterprise as a COBRA client

A remote COBRA server can also be accessed from within Comarch ERP Enterprise as part of adaptation. Comarch ERP Enterprise only contains the ORB, the related libraries and the documentation of the CORBA sample clients for Comarch ERP Enterprise itself as standard support because the access mode is entirely determined by the respective COBRA server.

Web service

A Web service uses the SOAP protocol for remote connections that can be used on diverse platforms. Another option is the implementation of the REST principles during the implementation of a Web service. They are an alternative to CORBA if no mass data has to be transferred, since Web services do not support stateful calls.

Comarch ERP Enterprise as a Web service server

Comarch ERP Enterprise contains a Web service server. It requires the HTTPS protocol. It uses a WSDL file to specify the data format of the interface (or SOAP) that the clients must use.

The functionality is available via the Web service interface in the same way as the CORBA server.

When the clients log on to the Web service server, authentication takes place using a password or user certificate and the authorizations in Comarch ERP Enterprise are verified.

More information can be found in article: Web Services Interface.

Comarch ERP Enterprise as a Web service client

Adaptations in Comarch ERP Enterprise can also access a remote Web service server. Comarch ERP Enterprise contains the related libraries and the documentation of the Web service sample clients for Comarch ERP Enterprise itself as standard support, since the access mode is entirely determined by the respective Web service server.

Native protocols

Other protocols, such as TCP/IP, FTP or Java RMI can also be used. They are particularly interesting for addressing external servers from Comarch ERP Enterprise via its interfaces. However, Comarch ERP Enterprise does not offer any support here in the standard.
If an adaptation in Comarch ERP Enterprise is to develop a server for a native protocol, it is recommended instead to develop this server outside of Comarch ERP Enterprise and to let it access Comarch ERP Enterprise via CORBA.

Combining various technologies

Performance-related issues

Protection against resource bottlenecks

Server systems such as Comarch ERP Enterprise cannot operate efficiently if too many remote calls have to be processed simultaneously by an application server. This can be avoided by taking appropriate measures.

Each session that a client opens via remote connections on a Comarch ERP Enterprise system consumes resources such as memory, computing time and database connections on the application server to which the client connects. If a use case requires a large number of clients, all of which are constantly connected to the CORBA server, resource bottlenecks (reduction in throughput) can occur. Critical resources in this case are mainly the sessions (and database connections). Each session occupies a Comarch ERP Enterprise thread from the moment it is created, i.e., heap memory for the threadstack and native resources depending on the operating system. During the processing of a request, a thread is occupied. If data must be read from the database to process a CORBA request, additional temporary database connections are also occupied.

Memory, threads and database connections are resource-limited on the application server. A resource bottleneck leads to a longer processing time for a remote connection. In the worst case, the stability of the entire application server can be jeopardized.

There are several ways to avoid resource bottlenecks. The basic idea is to coordinate access to critical resources in order to avoid too many simultaneous accesses.

In the first possible solution (Figure 1), several Comarch ERP Enterprise application servers are used to distribute client accesses. CORBA clients are used in the example, but the idea described is generally applicable.

By distributing data to several Comarch ERP Enterprise application servers, the memory consumption per application server is reduced. However, this solution can lead to a high load on the database if many requests are sent to the application servers at the same time.

In the second possible solution (Figure 2), a separate process (CORBA Proxy Queue) is used that is independent of Comarch ERP Enterprise. The client requests are first sent to this process, which queues them and then forwards a limited number of them to Comarch ERP Enterprise at the same time. This limits the number of CORBA sessions and the number of database connections in Comarch ERP Enterprise. The CORBA Proxy Queue acts as a server for remote connections and as a CORBA client. The implementation of such a queue can therefore be carried out in any programming language that is tailored to a specific case.

In both solutions presented, it is assumed that each process runs on its own computer and therefore has exclusive access to its limited resources. A CORBA Proxy Queue solution should also always run on its own computer.

When creating a connection to Comarch ERP Enterprise via remote calls, tests should be carried out taking into account the expected number of clients. This way, it is possible to determine whether resource protection measures are necessary in a specific case.