SData is the new Sage standard for Web Services. It is a REST based protocol similar to GData. Typically REST based protocols are “stateless”, meaning that any request doesn’t rely on knowledge of other requests. An SData request might be something like add an order where the order is provided as an XML payload; update a customer record where the new fields are in the XML payload. This is a very efficient way to do things. Each document entered just requires one round trip request from the client to the server.
“Stateless” processes are very desirable in large Web based applications. It means each request can be directed (load balanced) to one of a set of servers in a server farm. History doesn’t matter; each request can go to any server. If a process is “stateful” then requests from a given client have to be directed always to the same server. “Stateless” is also desirable since the server doesn’t keep any knowledge of things in progress, so no server resources are committed between calls. Also if the server is restarted, or a process on the server is restarted, besides perhaps a slight delay, the clients never know, since no info was kept in the process that was stopped.
However this typically isn’t how we enter orders from a User Interface form. From the User Interface we build up an order a piece at a time. First we input the customer number or an order template, from which we fill in a number of field defaults. Then typically we update some order header fields, and then enter a number of detail lines. As we enter things they are validated and often entering one field like a currency code or item number causes a number of other fields to be updated.
One way to do this would be to send the order to the server each time something happens and have it updated and sent back. This would keep things stateless, but would tend to become unwieldy as the order gets large. Another consideration is that we want to keep using the Accpac Business logic more or less unchanged.
The Accpac Business logic builds up the order inside the Business logic (View) as it goes along. Then when you say save, it commits everything to the database as one transaction. In this model as parts of the order are completed they get applied to the in-memory order, defaults are looked up and validations are performed. So typically an UI will issue a command to create a new order and receive back the default values and states for all header fields. Then the UI will enter the customer number or a template code, this will go to the business logic which will then validate this value and lookup the defaults, apply them to its copy of the order and pass them back to the UI. At each step the UI is really updating the server memory part of the order. The UI doesn’t need to keep all entered details in memory since it can ask the server for them at any time. When the order is saved, the UI just sends a save request (with no data) and the server commits the order from memory to the database in one database transaction.
So how do we reconcile stateless SData with stateful Accpac? Generally we try to keep as many things stateless as possible, but for some operations, mostly entering documents, we need to introduce state to SData. We add an SData call that will start “stateful” processing on a given SData resource like an order. This means then that SData will keep state on the resource, which under the hood means it will tie a View instance to the client and preserve it for the client. Then the UI rather than send the whole order, just sends the parts that the user changed (the UI has to know when to trigger this) and then SData applies these changes to the Accpac Views, and then gets all the fields that changed as a result (either in value or in state) and returns them as the return payload to the SData call. This then goes on until an SData call like a header navigate or save happens to clear the state. This means that while the Order is being compiled server resources are being used and all requests for this client have to be routed to this particular server.
In a Web Application like Facebook with say 500,000 users online at once, keeping any state on the server is incredibly expensive. Plus things need to be load balanced in the most flexible manner possible. But I think Accpac has a bit of breathing room before we reach this kind of volume. At least we are moving in the right direction, having many things stateless such as inquiries and simple file updates/inserts. We just keep state during document entry of header/detail type documents. But if Accpac does start having hundreds of thousands of users online then we will need to start evolving our business logic to become truly stateless. But for now we have a nice compromise of using our existing business logic, but becoming stateless in a lot of what we do.