Feedback from the Server

Dynamic View Services > Implementing a Dynamic View Server and its Components > Interaction Cycles > Feedback from the Server

As the beginning of “Interaction Cycles”., we said that three types of feedback may be returned when the server processes a component-to-server transaction:

notification about modifications to be done to component representations to maintain consistency with the associated server objects;

acknowledgement to the requesting component;

rollback of the updates initially performed by the requesting component on representations.

Such feedback involves requests from the server to the component(s). At component level, those requests are executed within server-to-component transactions.

The execution of a server-to-component transaction starts by a call to the virtual function IlsMvComponent::beginS2CTransaction and ends by a call to the virtual function IlsMvComponent::endS2CTransaction. You can override these functions to set specific processing at the beginning and/or at the end of the transaction. These functions take two arguments:

the type of feedback;

the identifier of the original component-to-server transaction.

Note that in the case of a notification, the transaction identifier is null, because there is no necessary link between a received notification and any transaction previously committed by the component. When you override the function beginC2STransaction, be aware of how the Boolean result is interpreted: when it is IlsFalse, the execution of the transaction stops and ends by a call to the function endC2STransaction.

The mechanism is fairly similar whether considered at representation level or at representation object level.

At representation level, the functions IlsRepresentation::beginS2CTransaction and IlsRepresentation::endS2CTransaction are implicitly called on each representation involved.

At representation object level, the functions IlsRpObject::beginS2CUpdate and IlsRpObject::endS2CUpdate is implicitly performed on each representation object involved. Then, for each attribute touched by the transaction, the virtual function IlsRpObject::ackAttrUpdate is called with the attribute identifier as its first parameter. In case of notification or rollback, the attribute is edited only when this function returns IlsTrue, the default.

Version 5.8