This section describes the artifacts that need to be developed in order to pre-populate a Life Event script. In this section we describe
The Data Hub is a means of collecting data about Citizens from many different locations and returning it as an XML document in a datastore. The Data Hub can be used to hide the complexities of where data comes from and how it is represented in it original locations. For example, to drive a "Lost my Job" Life Event it might be necessary to gather information about a person's Income, Address and Employment. These three pieces of information might be represented differently on the underlying system, indeed they might live on three or more different systems. The caller doesn't need to know this. The Citizen Data Hub allows its clients to get these pieces of information in one single operation. Operations of this type are named uniquely, each is called a "Data Hub Context". To animate the "Lost my Job" example we define a Data Hub Read Context called "CitizenLostJob" that allows the collection of Income, Address and Employment information in a single query.
One of the sources that the Data Hub can draw on is Evidence on Cases. In particular, Evidence on the Citizen's Holding Case. The Holding Case can use the Evidence Broker to gather data from many disparate Integrated Cases or even from other Systems via Web Services. The Holding Case is a little different from other Cases. There is only ever one per Citizen on a given Cúram system. The Holding Case has an interface that allows all of the Evidence it contains to be extracted in XML format. This XML format is optimized for the description of Evidence in particular. Because it is optimized for the description of Evidence, it isn't necessarily in a format suitable for insertion into a data store. Fortunately it is relatively easy to translate data in one XML format into another format that contains the same information. This can be done using a language called XSLT For more information on XSLT please refer to, http://www.w3.org/TR/xslt. The next section demonstrates how to write XSLT Transforms for use in the Data Hub.
To write Citizen Data Hub Transforms it is necessary to understand, the structure of the Holding Evidence XML that is the source data and the Data Store schema that is the target. The "CitizenLostJob" Life Event is significantly complex so, for the purposes of an introductory example, this section describes a simple fictitious Life Event for Citizens who have bought a new car. This Life Event is associated with the Data Hub Context "CitizenBoughtCar". This would not be considered a "Life Event" in the real world but it nevertheless provides an example of some of the principles of building a Round Tripping Life Event. For the purposes of this example consider this fragment of Holding Evidence XML that is used to describe a Vehicle:
<?xml version="1.0" encoding="UTF-8"?>
<client-data
xmlns="http://www.curamsoftware.com/schemas/ClientEvidence">
<client localID="101" isPrimaryParticipant="true">
<evidence>
<entity localID="-416020015578349568" type="ET10081">
<attribute name="vehicleMake">VM2</attribute>
<attribute name="versionNo">2</attribute>
<attribute name="startDate">20110301</attribute>
<attribute name="usageCode">VU1</attribute>
<attribute name="amountOwed">3,200.00</attribute>
<attribute name="numberOfDoors">0</attribute>
<attribute name="evidenceID">
-5315936410157449216
</attribute>
<attribute name="monthlyPayment">0.00</attribute>
<attribute name="vehicleModel">159</attribute>
<attribute name="year">2008</attribute>
<attribute name="equityValue">0.00</attribute>
<attribute name="endDate">10101</attribute>
<attribute name="fairMarketValue">17,000.00</attribute>
<attribute name="curamEffectiveDate">20110301
</attribute>
</entity>
</evidence>
</client>
</client-data>
The client element represents data belonging to the participant with concern role id 101. In Cúram demo data this is James Smith. The client contains a single evidence entity of type ET10081. In the Cúram Common Evidence layer, ET10081 is the Evidence Type identifier for Vehicle Evidence. The localID attribute plus the evidence type uniquely identifies the underlying evidence object for the Vehicle. This data has to be mapped to data store XML so that it can be used to populate an IEG Script. Consider how the above data is to be represented in data store XML:
<?xml version="1.0" encoding="UTF-8"?>
<Application>
<Person localID="101" isPrimaryParticipant="true"
hasVehicle="true">
<Resource resourcePageCategory="RPC4001"
localID="-416020015578349568" vehicleMake="VM2"
versionNo="2" amountOwed="3,200.00" vehicleModel="159"
year="2008" fairMarketValue="17,000.00"
curamEffectiveDate="20110301">
<Descriptor/>
</Resource>
</Person>
</Application>
This XML data must conform to the schema used to build the IEG script. Notice that the XML above conforms to a schema that is a superset of the CitizenPortal.xsd schema. It is recommended that the CitizenPortal.xsd schema be used as a starting point for the schemas used in Customer Life Events. To these schemas need to be added the "marker" attributes needed for Life Events. These marker attributes include the use of localID as discussed previously. Datastore schemata for entities can also include the following special markers that are specialized for representing Evidence in the Holding Case: The following XSLT fragment shows how to transform Vehicle Holding Evidence into a corresponding Data Store Entity:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:x="http://www.curamsoftware.com/
schemas/DifferenceCommand"
xmlns:fn="http://www.w3.org/2006/xpath-functions"
version="2.0">
<xsl:output indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:template match="update">
<xsl:for-each select="./diff[@entityType='Application']">
<xsl:element name="client-data">
<xsl:apply-templates/>
</xsl:element>
</xsl:for-each>
</xsl:template>
<xsl:template match="diff[@entityType='Person']">
<xsl:element name="client">
<xsl:attribute name="localID">
<xsl:value-of select="./@identifier"/>
</xsl:attribute>
<xsl:element name="evidence">
<xsl:apply-templates/>
</xsl:element>
</xsl:element>
</xsl:template>
<xsl:template match="diff[@entityType='Resource']">
<xsl:element name="entity">
<xsl:attribute name="type">ET10081</xsl:attribute>
<xsl:attribute name="action">
<xsl:value-of select="./@diffType"/>
</xsl:attribute>
<xsl:attribute name="localID">
<xsl:value-of select="./@identifier"/>
</xsl:attribute>
<xsl:for-each select="./attribute">
<xsl:copy-of select="."/>
</xsl:for-each>
</xsl:element>
</xsl:template>
<xsl:template match="*">
<!-- do nothing -->
</xsl:template>
</xsl:stylesheet>
The Life Event author who adds this transform to their Life Event can turn Vehicle Evidence recorded on any Integrated Case into a Data Store format that can be displayed in an IEG script with all the information pre-populated from the Evidence Record.
When the Holding Case is called upon to return an XML representation of its evidence, by default it will return all evidence for the citizen concerned. This could be a very large query that returns much more information than is required. The purpose of a Filter Evidence Link is to define, for each Data Hub Context, which Evidence Types are of interest. A Filter Evidence Link can be defined by adding entries to a Filter Evidence Link dmx file. The example below shows a Filter Evidence Link dmx file that defines the information that should be returned for the "CitizenBoughtCar" Life Event:
<?xml version="1.0" encoding="UTF-8"?>
<table name="FILTEREVIDENCELINK">
<column name="FILTEREVLINKID" type="id" />
<column name="FILTERNAME" type="text" />
<column name="EVIDENCETYPECODE" type="text" />
<row>
<attribute name="FILTEREVLINKID">
<value>175</value>
</attribute>
<attribute name="FILTERNAME">
<value>CitizenBoughtCar</value>
</attribute>
<attribute name="EVIDENCETYPECODE">
<value>ET10081</value>
</attribute>
</row>
</table>
Up to this point has focused on how Transforms can be used turn Evidence data into Data store XML for use in a Life Event Script. However there are other important pieces of information that are not represented as Evidence. In general the Life Event author must develop custom Java code in order to populate any information that is not represented as evidence. Using Java it is possible to develop View Processors which can be used to extract non-evidence data and translate this data into data store xml. By associating these View Processors with the right Data Hub Context, they can add their information into the data store in addition to the data put there by the transforms. The Life Events Broker ships with some pre-packaged View Processors that are capable of inserting certain frequently used non Evidence Data.
The Household View Processor will find all Persons related to the currently Logged in user and pull them into the data store along with information on how they are related to the logged in Citizen. This information is based on the CEF ConcernRoleRelationship entity.
The Person Address View Processor populates the most important details of the logged in Citizen, such as name and Social Security Number. It also pulls in the Residential and Mailing addresses of the logged in Citizen. Both the Household View processor and the Person Address View Processor can be used together in the same Life Event Context but the Person Address View Processor should be run after the Household View Processor. The excerpt below shows how to configure these two View Processors to execute for the "CitizenBoughtCar" Life Event.
<?xml version="1.0" encoding="UTF-8"?>
<table name="VIEWPROCESSOR">
<column name="VIEWPROCESSORID" type="id"/>
<column name="LOGICALNAME" type="text" />
<column name="CONTEXT" type="text" />
<column name="VIEWPROCESSORFACTORY" type="text" />
<column name="RECORDSTATUS" type="text"/>
<column name="VERSIONNO" type="number"/>
<row>
<attribute name="VIEWPROCESSORID">
<value>4</value>
</attribute>
<attribute name="LOGICALNAME">
<value>CitizenLostJob0</value>
</attribute>
<attribute name="CONTEXT">
<value>CitizenBoughtCar</value>
</attribute>
<attribute name="VIEWPROCESSORFACTORY">
<value>
curam.citizen.datahub.internal.impl.
+HouseholdCustomViewProcessorFactory
</value>
</attribute>
<attribute name="RECORDSTATUS">
<value>RST1</value>
</attribute>
<attribute name="VERSIONNO">
<value>1</value>
</attribute>
</row>
<row>
<attribute name="VIEWPROCESSORID">
<value>5</value>
</attribute>
<attribute name="LOGICALNAME">
<value>CitizenLostJob1</value>
</attribute>
<attribute name="CONTEXT">
<value>CitizenBoughtCar</value>
</attribute>
<attribute name="VIEWPROCESSORFACTORY">
<value>
curam.citizen.datahub.internal.impl.
+CustomPersonAddressViewProcessorFactory
</value>
</attribute>
<attribute name="RECORDSTATUS">
<value>RST1</value>
</attribute>
<attribute name="VERSIONNO">
<value>1</value>
</attribute>
</row>
</table>
Note the use of the CONTEXT field. This links the ViewProcessor to the "CitizenBoughtCar" Life Event Context. This ensures that this ViewProcessor is called whenever the "CitizenBoughtCar" Data Hub Context is called. Notice also the use of a logicalName which uniquely distinguishes each View Processor. View Processors for a given Data Hub Context are executed in lexical order, so a View Processor name with a logicalName of "AAA" for the DataHubContext "CitizenBoughtCar" will be executed before one with a logicalName of "AAB".