public interface TransactionChaining
DSRequests to be "chained" together, such that later
DSRequestsin the queue can use the results of previous requests in the queue. This allows you to declaratively handle various situations where information only becomes available during the processing of a queue.
Transaction Chaining is only available with Power Edition licenses or better. See the Editions & Pricing page for details.
As an example of Transaction Chaining, consider an application that needs to do a
master-detail add, which involves saving a new Record representing a sales order to an
order DataSource, and also saving several related Records representing
individual items in the order to an
orderItem DataSource. The Records for the
orderItems need to set up foreign keys referencing the primary key
assigned to the Record for the
order, but the primary key of the
order record is assigned only when the Record is inserted into the database; it
cannot be known up-front.
You could resolve this programmatically - for example, you could use DMIs to store and
retrieve the PK value using
servletRequest attributes - but Transaction Chaining
gives you an elegant, declarative, code-free alternative, giving you a way to declare that the
foreignKey value for the
orderItem records should use the primary key value
resulting from the creation of the
order record earlier in the same queue.
As another example, consider an application that allows a user to submit a free-form question which must be persisted to the database like a normal update, but which should initially show the user a list of previously-provided answers that appear to be relevant. The operation that handles the add of the question categorizes it by analyzing the text, and the category is added to the record inserted into the database, and thus to the record returned in the response. Now, via transaction chaining, a "fetch" operation later in the queue can pick up the newly assigned category and use it in criteria to fetch the list of related answers.
Transaction Chaining is implemented by specifying
These two properties
provide a general means of declaratively modifying DSRequests server-side, and transaction
chaining is only one of their uses. They can also be used, for example, to implement security
rules, by adding the currently-authorized user to the criteria of all fetch requests.
Specifically for transaction chaining, you specify
values entries on the
operationBinding where the
value property references the
Velocity context variable - see the "value" link for more details.
Alternatively, you can use the
getLastResponse() to get access to the same information, either
programmatically from DMI or custom DataSource Java code, or in
JSR 223 scripts, or in Velocity expressions via
fieldValueExpressions. The primary intended use case is a master-detail add, where the detail records require the master's primary key for use as foreign keys, but that value is not known until the master record has been inserted. In such a case, you create a
queueof requests, with the add of the master record first, followed by the detail records, each of which has
fieldValueExpressionsset up to use
DSRequest properties = new DSRequest(); Map fve = new HashMap(); fve.put("fkField", "$masterId"); properties.setFieldValueExpressions(fve); myDataSource.addData(record, callback, properties);It is also possible to achieve the same thing in a less compact but more flexible way by using the
$responseDatacontext variable (note that client-driven usages of
$responseDataare limited for security reasons - see
fieldValueExpressionsfor details). This approach allows you to reference values where there is no declared foreignKey relationship, and it allows you to reference responses other than the most recent one. For example:
DSRequest properties = new DSRequest(); Map fve = new HashMap(); fve.put("anyField", "$responseData.first.anyOtherField"); properties.setFieldValueExpressions(fve); myDataSource.addData(record, callback, properties);
Standalone DataSource Usagefor examples on how to do this.