Generally the procedures and functions that make up the API of a Business Entity should be designed to be invoked independently of one another. In a state-free application server environment, there is really little choice, as you cannot maintain context between calls without binding an application server session, and you do not have the ability to get back to the same application server session you called before.

In many cases, however, a larger business task may require multiple successive calls where each application server procedure must be aware of the previous calls. There are at least two basic ways to approach handling this:

  • The first is to pass context along with each call. This is practical if the amount of data is not excessive and if the client needs or actually produces some of the context information needed on the server. One way to do this is to include a context temp-table definition as part of the ProDataSet definition. In this way the context is identified as an essential part of the Business Entity, and always passed along with its other data. This temp-table could contain a single row with fields representing scalar context values, or it could contain multiple rows representing any sort of tabular data.

    If you use a standard naming convention for the context table, such as ttContext, then even a general purpose procedure on the client can routinely pass this table as input to any server call that requires context. For example, if one or more tables in the ProDataSet require batching, to avoid reading and passing all rows at once, then the context table could contain the key values for the last row retrieved by the previous batch, and perhaps also the selection criteria used for the query. The server batching procedure could receive the context table alone as input, repopulate an instance of the ProDataSet with the next batch of rows and return the ProDataSet, including the context table with the new identifier for the last row retrieved, to the client.

  • The second method is to store the context persistently on the server, either in a database table or a file or in some other place where all application server sessions can read it. The CONNECTION-ID can be used as a key to differentiate one client's context from another's.