The section provides information about the Waveset objects that are used to implement optimistic checkouts.
The UserViewConstants.java file defines the following options to support optimistic checkouts. These can be set as view options when the User View is checked out in the same manner as existing view options.
OP_OPTIMISTIC - If this option is set to True, optimistic checkout semantics are enabled. This option must be set at view checkout time and at view checkin time so that a baseline copy of the view can be taken and optimistic reprovisioning can occur. This baseline copy of the view is used during the subsequent view checkin to determine any intervening changes that may have occurred to the same User by other Update User workflow reprovisioning operations. These intervening changes, if any, are compared against the local changes to determine if any conflicts are present and, if not, to merge the local changes with the intervening remote changes to complete the reprovisioning process for that User.
OP_OPTIMISTIC_RETRY_COUNT - The number of times a caller can to retry a reprovisioning operation. The default value is 3 times.
The reprovisioning operation attempts to lock the User repository object and ensures that no pessimistic Update User workflow is running for the same User before performing optimistic reprovisioning. If either of these conditions are not met, the task retries after sleeping for the specified interval. If the retry count is exceeded, an exception is thrown.
OP_OPTIMISTIC_RETRY_INTERVAL - The number of milliseconds to wait between reprovisioning retries. The default value is 30,000 milliseconds (30 seconds).
OP_IGNORE_CONFLICTS - This view option can be passed at user view checkin time to force the local changes to be committed. If it is set and evaluates to True, then the reprovisioning behaves in an optimistic manner with the exception that conflicts, if found, are not considered an error. Merging is still performed with local change values being committed in cases of conflict, thus overwriting these conflicting intervening changes. Non-conflicting changes are preserved. In the case where no other errors occurred but conflicts were found and OP_IGNORE_CONFLICTS is set to true, the WavesetResult will contain a named result (called conflicts) but will not have an error result set.
The following example enables optimistic checkout in a JSP (such as account/modify.jsp):
try { String id = requestState.getParameter(requestState, "id"); if (id == null) { form.setTitle(Messages.UI_ACCT_CRT_USR_TITLE); form.setViewId("User"); } else { form.setTitle(Messages.UI_ACCT_EDIT_USR_TITLE); form.setViewId("User:" + id); // Set this option so that checkin of the view // won't launch a reprovision. This does however mean that the user // changes will be stored. Need to be able to defer this. // requestState.setOption(UserViewConstants.OP_NO_REPROVISION, "true"); requestState.setOption(UserViewConstants.OP_SELECT_RESOURCES, "true"); // Enable Optimistic Checkout requestState.setOption(UserViewConstants.OP_OPTIMISTIC, "true"); // Set this options to true to build the // "Forwarding Approvers" select list req.setOption(UserViewConstants.OP_BUILD_APPROVER_LISTS, "true"); }
Conflicts, if any, are returned in the WavesetResult returned by WorkflowServices#reProvision() in a named GenericObject called conflicts. This is normally further returned in the GenericObject result from the call to view checkin. This object contains an attribute named accounts which is a list, by account, of attribute conflicts for that account.
For each such conflict detected, a GenericObject representing the conflict is created whose name is the name of the attribute.
The following example shows a set of conflicts.
<Object> <Attribute name='accounts'> <List> <Object name='SimRes1'> <Attribute name='conflicts'> <List> <Object name='attr1'> <Attribute name='local' value='Safari Attr1'/> <Attribute name='original' value='Orig Attr1'/> <Attribute name='remote' value='Firefox Attr1'/> </Object> <Object name='idmManager'> <Attribute name='local' value='Mr. Safari'/> <Attribute name='original' value='Mr. Orig'/> <Attribute name='remote' value='Mr. Firefox'/> </Object> <Object name='email'> <Attribute name='local' value='safari_email'/> <Attribute name='original' value='orig_email'/> <Attribute name='remote' value='firefox_email'/> </Object> </List> </Attribute> </Object> <Object name='Lighthouse'> <Attribute name='conflicts'> <List> <Object name='idmManager'> <Attribute name='local' value='Mr. Safari'/> <Attribute name='original' value='Mr. Orig'/> <Attribute name='remote' value='Mr. Firefox'/> </Object> <Object name='email'> <Attribute name='local' value='safari_email'/> <Attribute name='original' value='orig_email'/> <Attribute name='remote' value='firefox_email'/> </Object> <Object> <Attribute name='roleInfos'> <List> <Object name='IT Role1'> <Attribute name='local'> <GenericAttribute> <Object> <Attribute name='attribute'> <Object name='IT Role1'> <Attribute name='assignedBy'> <List> <String>Business Role 2</String> </List> </Attribute> <Attribute name='assignmentType' value='required'/> <Attribute name='state' value='assigned'/> <Attribute name='type' value='ITRole'/> </Object> </Attribute> </Object> </GenericAttribute> </Attribute> <Attribute name='original'/> <Attribute name='remote'> <GenericAttribute> <Object> <Attribute name='attribute'> <Object name='IT Role1'> <Attribute name='assignedBy'> <List> <String>BusinessRole1</String> </List> </Attribute> <Attribute name='assignmentType' value='required'/> <Attribute name='state' value='assigned'/> <Attribute name='type' value='ITRole'/> </Object> </Attribute> </Object> </GenericAttribute> </Attribute> </Object> </List> </Attribute> </Object> </List> </Attribute> </Object> </List> </Attribute> </Object>
In this example, conflicts have been detected in two accounts: SimRes1 and Lighthouse. The attributes on SimRes1 for which conflicts have been detected are attr1, idmManager, and email. For Lighthouse, the attributes in conflict are idmManager, email, and roleInfos. For each conflict the original, remote, and local changed values are listed. The original value is the value of the attribute at the time the view was checked out. The remote value is the value of the attribute present in the repository (or on the resource) at the time reprovisioning started. The local value is the changed value of the attribute made by the currently executing task.
The idmManager attribute had a value of Mr. Orig when the currently running task checked out the User view (the original attribute value). The current task changed that value to Mr. Safari (the local attribute value). However, in the interim, one or more other changes have been committed which changed the attribute value to Mr. Firefox (the remote attribute value). This constitutes a conflict because the remote changes (Mr. Safari) would be lost if the local changes were committed.