View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Add page
Show collection (0 pages)
Collections help

Search

Multi-Server Process Calls Concept

Bulbgraph.png   This feature is available starting from 16Q3

Contents


Introduction

OB Commerce supports a multi-server architecture with a central server and store servers for each store.

It is important for developers to consider that their functionality will operate in this environment. OB Commerce provides a standard infrastructure which can be extended by developers to facilitate developing of multi-server code. Multi-server code makes use of the central and store server architecture to provide a more robust and more performing environment for the end user.

An important feature which can be extended by developers is the so-called 'Multi-Server Process Call'. The OB Commerce multi-server process call concepts makes use of the availability of different servers and automatically replays process calls on servers.

This page gives an overview of the inner working of the multi-server process call concept. The logic described here is provided out-of-the-box. The developer only needs to focus on the application code. Still it is good for a developer to understand the overall flow of information and messages in a multi-server environment.

How-To

This document focuses on the underlying concepts and main flow of the multi-server-call infrastructure. A separate how-to provides the details of each of the steps needed to implement a multi-server process call.

System Environment

The description below uses a standard system environment consisting of a WebPOS system, a store server and a central server.

In practice there will be multiple WebPOS systems connected to a Store Server and multiple Store Servers connected to a Central Server.


System-Environment-Multi-Server-Call.png


A WebPOS system will mostly directly communicate with the Store Server. If the Store Server is not available then the WebPOS system will automatically switch to the Central Server.

Multi-Server Scenarios

The next sections describe how the Multi-Server-Call concept operates in different system scenarios.

The description illustrates how the concept provides additional (for the developer out-of-the-box) robustness. Keeping the WebPOS clients in operation even in case of server failures and store disconnects.

Online

The online scenario is the most common case. The WebPOS communicates with the Store Server and the Store Server has direct access to the Central Server. There are no interruptions in connections and all systems are online. The multi-server call flow is described in the slide below.


Multi-Server-Call-Flow-Online.png

Store disconnected from Central

In this scenario the Store Server can not connect to the Central Server. This happens for example when the store has lost connection to the net.

The WebPOS communicates with the Store Server, so sales and other operations can continue.

The Store Server detects that the Central Server is not reachable and will Transition to Offline.

In Offline state, the Store Server will store the transactions in its so-called Import Entry buffer. When the Central Server reconnects the buffer is flushed to the Central Server and the actions are replayed on the Central Server.


Multi-Server-Call-Flow-Store-Offline.png


Store Server down

In this scenario the Store Server itself has stopped operation. The WebPOS automatically detects this and will switch to the Central Server.

The Central Server will store the transactions in its so-called Import Entry buffer. When the Store Server is back then the buffer is flushed to the Store Server and the actions are replayed on the Store Server.


Multi-Server-Call-Flow-Store-Server-Down.png


Default: Store Server First

The default approach for the Store Server functionality is to first execute the action in the store and then in the central server. This default mode is used if the Central Server First approach is not explicitly enabled. So no special settings are needed to enable this approach.

Store Server Only

As 'Store Server First' is the default behavior, the only thing to do to enable 'Store Server Only' is to tell the system to only process in one server. This is accomplished by setting the '_executeInOneServer' to true in the request:

'_executeInOneServer': true

Or by overriding the executeInOneServer method in your subclass and returning true:

protected boolean executeInOneServer(JSONObject json) throws JSONException {
    return true;
}

Central Server First

For some functionalities it is important that the process is first executed centrally before the process is replicated in the store server. For example when integrating with an external stock system it can be better to do this from the Central Server. To have one single point of integration.

For this specific case it is possible to run the Multi-Server-Call in a special mode: central-first-try. This is controlled through a simple json property in the request from WebPOS to the Store Server:

'_tryCentralFromStore': true

Or by overriding the executeFirstInCentral method in your subclass and returning true:

protected boolean executeFirstInCentral(JSONObject json) throws JSONException {
    return true;
}

The details of the flow are described in the slide below.


Special-Case-Multi-Server.png


The central first approach can be combined by with a property to only let the action be executed in maximum one server: first try central, if it succeeds then do not execute in the store, if it fails then try the action in the store.

This behavior is enabled by setting the '_executeInOneServer' to true in the request:

'_executeInOneServer': true

Or by overriding the executeInOneServer method in your subclass and returning true:

protected boolean executeInOneServer(JSONObject json) throws JSONException {
    return true;
}

Central Server Only

For some functionalities it is important that the process is only executed centrally. Even if the request is received on the store it is forwarded to the central server and the response is send back to the WebPOS client. If the central server is not online/available then an error is returned to the WebPOS client.

This mode is controlled through a simple json property in the request from WebPOS to the Store Server:

'_onlyDoCentralFromStore': true

Or by overriding the executeFirstInCentral method in your subclass and returning true:

protected boolean executeOnlyInCentral(JSONObject json) throws JSONException {
    return true;
}

Note: the central server only mode can be enabled in two ways: 1) using _onlyDoCentralFromStore as described here, 2) or by combining 'Central Server First' with execute in one server property as described in the 'Store Server Only' section.

Retrieved from "http://wiki.openbravo.com/wiki/Multi-Server_Process_Calls_Concept"

This page has been accessed 362 times. This page was last modified on 9 November 2016, at 11:15. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.