Page 308 -
P. 308

304                                                        M. Adams





                           Fig. 11.6 The Issue Shipment Remittance worklet














                           Fig. 11.7 The Prepare Payment Order worklet



                              At this stage, two worklets have been defined as possible substitutes for a task
                           (either payment has already been received, or it hasn’t). But now consider the
                           situation where a partial payment has already been received. In the non-worklet
                           version of the Payment subnet, this new scenario would require a reworking of the
                           entire net, with a new branch introduced to accommodate it. In the worklet-enabled
                           version, all that is required is for a new worklet to be defined and added to the reper-
                           toire for the task, which demonstrates the advantages the worklet approach offers
                           over monolithically designed processes, or statically defined subnets. Any number
                           of worklets can be created for a particular task.
                              The Issue Shipment Invoice task is associated with the Worklet Service (i.e.,
                           the task is “worklet-enabled”) via the Editor’s Update Task Decomposition dialog
                           (Fig. 11.8). This dialog shows the variables defined for the task – each one of these
                           maps to a net-level variable, so that the data collected for an order earlier in the pro-
                           cess may be made available to this task. The result is that all of the relevant current
                           case data for this process instance can be used by the Worklet Service to enable a
                           contextual decision to be made. Note that it is not necessary to map all available case
                           data to a worklet-enabled task, only those data required by the service to make an
                           appropriate decision via the conditional expressions in the rule nodes defined for the
                           task. The list of task variables in Fig. 11.8 shows that the POrder variable is defined
                           as “Input Only,” indicating that the value for that variable will not be modified by
                           any of the worklets that may be executed for this task, but it may be used for the
                           selection process. The other variables are defined as “Input & Output” or “Output
                           Only,” so that the worklet can modify and return (i.e., map back) to those variable
                           data values that are captured during the worklet’s execution. The dialog includes a
                           section at the bottom called YAWL Registered Service Detail.Itis herethatthe task
                           is associated with the Worklet Service (i.e., made worklet-enabled) by choosing the
                           Worklet Service from the list of available services.
   303   304   305   306   307   308   309   310   311   312   313