Caching ISF

A typical pattern occurs when an application creates an outbound transaction that must be sent as a single transmission. When sending outbound single transactions for transmissions the following steps usually occur:
  • Call A_CreateOutboundTxn()
  • Call A_RouteAndSendOutTxn() or an equivalent function
Typically, the create action builds an ISF tree in memory, serializes it, and inserts the transaction into the database. Then, in the same unit of work, the send action needs to get the transaction details, including the ISF, to fulfil the transmission.
The begin outbound mapper flow now supports retrieval of single, or non batch, transactions from a cache location on the environment. The create action must build its ISF tree in the cache and leave it there for BeginOutboundMapper to find. The begin outbound mapper flow simply checks the cache for data before trying the database. If the data is found, it is removed from the cache and passed into the mapper as if it had come from the database. This technique avoids:
  • Performing a database select, including the retrieval of 1-2KB of ISF data
  • Parsing the ISF
This technique is demonstrated in the sample application. The following code extract from the sample application demonstrates how an action should do this:
DECLARE rNewIsf REFERENCE TO Environment;
CALL GetRefToIsfCache(rEnv, nNewId, rNewIsf);
CREATE LASTCHILD OF rNewIsf AS rNewIsf NAMESPACE isf NAME 'ISFMessage';
SET rNewIsf.Header.BusinessConcept = BC_LIQUIDITY_REQUEST;
SET rNewIsf.Header.MasterTransactionId = nCurrentTxnId;
SET rNewIsf.Header.TransactionId = nNewId;
SET rNewIsf.{isfs}:LiquidityRequest.RequestType = BC_LIQUIDITY_REQUEST;
Note: The call to the GetRefToIsfCache() function takes a reference, rNewIsf, and moves it to point to a valid cache entry for the supplied transaction ID, nNewId. The remaining action code builds the tree as usual. However, you must not delete the tree after serializing the ISF.