Analysis

The distinction between these Round Tripping Life Events and Standard Life Events is determined by whether the data that is pre-populated into the Life Event is allowed to be changed by the user. If the Citizen is expected to update pre-populated information, rather than just adding new information then the Life Event should be considered a Round Tripping Life Event. It is considerably harder to develop this type of Life Event. The Advanced Life Events subsystem is designed to cater for Round Tripping Life Events. This chapter provides information on how to develop an Advanced Life Event that supports Round Tripping of the client's information.

The primary artifacts that constitute an Advanced Life Event are:

• An IEG script and its associated data store schema
• An IEG script to review answers in a previously submitted Life Event (optional)
• An Recommendations Ruleset, that produces the set of recommendations based on the information entered in the IEG script (optional)

The Life Events system can take information entered by the user and do either of two things with that information:

1. If the user is linked to the local Cúram case processing system, then the Life Events system can update related evidence in any cases they have.
2. If the user is linked to remote systems then the Life Events system can send updates to related remote systems via web services.

The Life Events system can be configured to seek the user's permission before sending Life Event information to any remote systems.

A standard Life Event that is configured only to send information to remote systems can be configured through the administration application. See Universal Access Configuration Guide for details.

If the Life Event is a Round Tripping Life Event or it is required to update evidence in the local case processing system then some development work will be needed to configure the Life Event. Round Tripping Life Events must be pre-populated. Currently pre-population of Life Events is only supported for users linked to the local Cúram case processing system via a concern role. To read information from cases and update those cases, the Life Events system relies on a subsystem called the Citizen Data Hub. The remainder of this section outlines the work needed to configure the Citizen Data Hub.

The Life Event Broker uses the Data Hub to get the data it needs to populate the Life Event, so the developer must configure the Data Hub to extract this data. The Life Event Broker also sends the updated data back through the Data Hub. The Data Hub must be configured to tell it what to do with this updated data.

These are some of the artifacts used to configure the Citizen Data Hub for reading information:

• Transform - Translates data from the Holding Case into Data Store XML
• Filter Evidence Links - When reading Citizen Data, these filter out only the evidence entities of interest when reading from the Holding Case
• View Processors - Java classes for extracting non evidence data into the Data Store XML

These are some of the artifacts that are used to configure the Citizen Data Hub for updating information:

• Transforms - Convert a Data Store XML Difference Description back into Holding Case Evidence
• Update Processors - Perform other update tasks or update non evidence data relating to the Citizen