Leveraging work parties in routing

Adding work parties to case types allows for consistent design and can simplify configuration of routing throughout the case life cycle. The layer of abstraction provided by work parties aids the developer by providing a dynamic, extensible and reusable routing solution. Using work parties in your solutions allows you to leverage related base product provided functionality such as a ready to use data model, validation, UI forms and correspondence which simplifies design and maintenance. The basic configuration for work parties have already been described in pre-requisite missions. This topic will concentrate on forming a deeper understanding of work party functionality and routing configuration to aid the developer in fully leveraging this functionality.

Most of the existing code for work parties is contained in the Data-Party class which provides the base functionality and orchestration for rules in derived classes. Several classes extend Data-Party, such as Data-Party-Operator which overrides the base functionality. It is important to understand this polymorphic behavior since the behavior will change depending on the class used to define the work party. For example, work party initialization, validation and display will differ between work parties constructed from the Data-Party-Operator class compared to those constructed from the Data-Party-Person class. You are encouraged to review and compare the rules provided in the Data-Party class and subclasses to gain an appreciation for the base functionality and specialization provided.

An example of a polymorphic rule is the WorkPartyRetrieve activity. This activity is overridden within the Data-Party-Operator and Data-Party-Person derived classes.

The WorkPartyRetrieve activity is significant since it is invoked every time a page is added to the .pyWorkParty() pages embedded on the Case. The .pyWorkParty() page group stores the invidual parties added to the case. The property definition contains an on-change activity which ultimately invokes the WorkPartyRetrieve activity.

It may be required to override the default behavior of some aspect of the work parties such as validation or display. This can be performed either through ruleset specialization or by extending the work party class and overriding the required rules. If this is required, ensure the scope of the changes are made correctly so not to change behavior in unintended ways.

A Work Party rule defines a contract which defines the possible work parties which can be utilized in the Case. Define work parties for the case in the standard work parties rule pyCaseManagementDefault. Use meaningful party role names to enhance application maintainability. Avoid generic names such as Owner and Originator. Generic, non-descriptive role names such as Owner can be subject to change and may not intuitively describe the party’s role with respect to the case.

You can use the visible on entry (VOE) option to add work parties when a case is created. VOE allows you to:

• Enable the user to add work parties in the New harness
• Automatically add the current operator as a work party
• Automatically add a different operator as a work party

Use the data transform CurrentOperator in the work parties rule to add the current operator as a work party when a case is created, example shown below. You can create custom data transforms to add other work parties when a case is created.

Prior to routing to a designated work party, the work party property values must be initialized. This can be performed at the time the case is created as described above using the VOE option on the Work Parties rule or it can be performed dynamically during case processing. When dynamically setting the work party values, leverage the addWorkObjectParty activity. This also allows you to specify a data transform to initialize the values. Caution must be used when using this activity however if the work party already exists and is not declared repeatable.