Features

Stateless #

SICS API Server is designed to operate in a stateless manner. In other words, each SOAP call must contain the data that is necessary for SICS API Server to fully process the SICS business function. Parts of the data may consist of references to data that already exist in the SICS operational database.

Commit / Rollback / Unit of Work #

Each SOAP call to the SICS API Server will either succeed 100% or fail completely. In the case of success all changes to SICS data will be committed to the database - as a single transaction. In the case of failure, the database stays unchanged.

Currently, two-phase commit is not supported. In our view it adds too much overhead, complicates the processing and does not fit very well with the idea of loosely coupled systems.

Multi-user, Serialized Processing #

Due to its statelessness, SICS API Server can handle requests coming in from different users. However, only a defined number of requests will be processed at a time, in order to avoid uncontrolled memory consumption. If another request arrives while SICS API Server is already processing the maximum number of concurrent requests, the new request will be queued. As soon as SICS API Server finishes processing one request, the next one in queue will be served.

It is possible to increase or decrease the maximum number of concurrent requests or to start several instances of SICS API Server. This last option would be useful if the overall inflow of requests is too high for one instance of SICS API Server to handle, and is described in further detail below.

Throughput / performance #

Processing time for a function is comparable to the response time for the same function in the SICS on-line system. SICS API Server uses the same business processes and therefore the same program logic (hence similar performance).

Logging and resend #

The client can request logging of messages to the SICS database. This can be used to avoid multiple processing of the same message (in cases of unexpected network problems and program crashes). It can also be used to collect statistics on processing time and distribution of services.

Security #

The Web Services are accessible through the SOAP protocol. HTTP(S) is used as the transport mechanism underneath SOAP. SICS API Server also support logon and user tokens.

Impersonation #

When SICS API Server is started, it will automatically log in to the SICS operational database using a username and password that is provided in the web application (web.xml).

By including a user name in the SOAP message SICS API Server will execute on behalf of this user. This ensure that SICS API Server clients can reuse SICS internal security (access right) and activity logging (event log etc).

Caching #

When SICS API Server is started, it will automatically cache various reference items (countries, currencies, reference data, entry codes, etc) in the same manner as SICS online. These are data that are supposedly quite static. Other types of data like, claim, business, accounting, etc, are not cached. This zero-caching is essential in a larger setup where several SICS API Server instances are running with some sort of load balancing.

Scalability / Load balancing #

Starting from version 4.5.1, SICS API Server can process multiple requests concurrently. The maximum amount of concurrent requests can be specified in web.xml and can be modified at anytime through a JMX bean or a specific Web Service, assuming that the user making the request has specific administration rights.

To a limited extent, also increasing the processor speed or the available memory can scale SICS API Server. Further scaling can be realized by adding more SICS API Server instances (using additional processors). Load balancing can then be achieved by utilizing standard message bus / load balancing software.

See SICS API Server - Installation Guide for more details.

Failover #

Since SICS API Server is designed to be a component in an Enterprise Architecture, SICS API Server does not itself provide any failover mechanism. That is, SICS API Server does not contain a layer for routing messages to different SICS API Server instances. If a calling application tries to open a connection to SICS API Server (using the IP address where SICS API Server is supposed to run) and SICS API Server is not running, the calling application will receive a TCP/IP “Connection refused” or “time-out” error.

Failover mechanisms could (should) be added through the use of an EAI Architecture like e4 or similar.

Resilience and Error Handling #

SICS API Server is designed to be robust. An exception handler in SICS API Server’s Web Services framework catches business level errors that would otherwise cause the runtime to abend (terminate) with a walkback (this is similar to how SICS works when executing in batch mode). Instead of terminating, SICS API Server will generate a SOAP Fault containing information about the nature of the error and a description of the error, return the SOAP Fault to the sender, reset itself and be ready to accept the next incoming message.

Client support #

SICS API Server comes with ready-generated client proxy files for Microsoft.NET, Apache Axis and JAX-WS.