Using Your Application as a Client
To use an application as a client in an OLTP environment, select the OLTP Client option for the OLTP Participation Segment configuration properties under the OLTP category for your relevant Configuration. You should also set to True the OLTP Client configuration property under the Environment for each Report that is going to participate in the OLTP transaction.
After generation (using that Configuration), any Ispec or OLTP Report in your application can then act as an OLTP client, and initiate OLTP service requests. Such requests can be to another application, or to an external OLTP server.
For OLTP services, destination Ispecs are defined in the same way as for External Automatic Entry transactions, by using the AutomaticEntryCapable model property, the IsExternal property or both.
How a Client Transaction is Processed
A transaction sent from your application is processed in the following way:
If your application is a client and uses Two-Phase commit, a Global Transaction (GTR) is initiated. The decision to start a GTR is made at the start of the client transaction, before the user logic is started.
If the transaction is a part of a GTR, the built-in attribute Glb.TwoPC defaults to Y. The client can reset the value of Glb.TwoPC to N indicate that a subtransaction initiated by the Send() built-in persistent class method on the target attribute should not use Two-Phase commit, and therefore not be part of the GTR. If not, the sub-transaction is included in the GTR.
Your logic sets the built-in segment attribute Glb.Destination to the OLTP Service name, Glb.DestHost to GLB.OLTP, and Glb.OLTPSubType to window-ispec (for MCP based applications).
Your logic uses the Initialize() built-in Ispec method on this target attribute, SetMaint() built-in Ispec method on the target attribute, Send() built-in persistent class method on the target attribute to move the required data into the Automatic entry buffer.
Your Send() method is executed, and sends the data to the OLTP CRM, which routes it to the appropriate server.
Processing is suspended until a response is received, or the OLTP transaction timeout is exceeded.
If no processing exception occurred at the server, Glb.Status is set to DATA or spaces, and Glb.HubStatus is set to OK. If there is a response from the server (Glb.Status is DATA), the Automatic Entry buffer contains the data, which can be accessed by invoking the Initialize built-in Ispec method on this target attribute and by doing a value assignment of the corresponding member of the target attribute to the target variable.
If the response from the server indicates a processing fault and your client system is using Two-Phase commit (2PC), your transaction is aborted immediately, and might either be replayed or automatically return an error.
If a processing exception occurred at the server, or if an exception was detected within OLTP routing which prevented the normal processing of the message by the named service, Glb.Status is set to five asterisks (*****), and Glb.HubStatus is set to an appropriate error message. The buffer contains any response that is received, or the original output message, or spaces (if the Send built-in persistent class method was invoked).
The built-in Segment attribute Glb.OLTPType and Glb.OLTPSubType are set to the buffer Type and Subtype names of the response buffer.
Ispec logic is processed in the standard way, although there are some differences in logic commands and built-in Segment attributes. Refer to Using Logic for OLTP for more information.
Within your Report logic:
The CriticalPoint command is always treated as an end of the current and start of the next Global Transaction.
The Sleep command is normally treated as an end of the current and start of the next Global Transaction. This is the default.
Use the NO.COMMIT; option on the Sleep command to circumvent the termination of the current Global Transaction.
Notes:
If the transaction is not committed, any current locked resources remains locked after the Sleep command.
For an MCP based application, using the NO.COMMIT; option on the Sleep command will not prevent the local database transaction from being committed, and any locked resources is released.