Subscriber Location Normalizer Example

This example steps through every section of a Subscriber Location Normalizer to examine how it processes an input location and transforms it into the desired output location convention. In this example, the foreign system is the publisher and CTS is the subscriber, so data is translated from the foreign system's location convention to the CTS convention.

The foreign assignment system sends data to CTS in the web service request. In this example, an element of the web request looks similar to the following:

<Location>
   <LocationID>23<LocationID>
   <UnitZone>VND 1<UnitZone>
   <Room>RM 103<Room>
   <Bed>1<Bed>
   <Facility>Vendor_Validation<Facility>
<Location>
<Role>PCT</Role>

CTS expects data from the web request in this format, and the adapter knows how to assign these values to variables that the normalizer understands. CTS parses the data it receives in this web request, automatically maps it to the following fields, and provides it as input to the normalizer:

Web Service Field Input Variable Value

<Facility/>

/location.facility

Vendor_Validation

<UnitZone/>

/location.unit

VND 1

<Room/>

/location.room

RM 103

<Bed/>

/location.bed

1

<Role/>

/role

PCT

The /location and /role prefixes indicate that the values of these variables are assigned by the foreign system. Alternatively, the $ prefix for a variable indicates that its value is being processed and assigned by the normalizer. Consequently, the normalizer in this example needs to accept the following input and transform it into the following normalized format that is used by CTS:

Node Input Input Value Node Output Output Value

/location.facility

Vendor_Validation

$facility

Vendor_Validation

/location.unit

VND 1

$unit

VND 1

/location.room

RM 103

$*

$1

$room

RM 103

RM

103

/location.bed

1

$bed

1

The following illustration provides an example of a normalizer that can accept the input in the format shown in the above table and provide output in the normalized format that is used in the CTS.

The four <node/> elements in this example successively process the four parts of a location from a Rauland Responder system: facility, unit, room, and bed.

The first node (shown in the following code fragment) takes as input a string identified by the Rauland system as the facility and allows it if it matches the string <pattern/> Vendor_Validation; the (?i) flag makes this pattern case-insensitive.

<node>
   <input>/location.facility</input>
   <pattern>(?i)Vendor_Validation</pattern>
   <variables>$facility</variables>
   ...

Since our sample input facility meets this criterion, the node processes it and assigns the input directly to the $facility variable without transforming it. Because the <format/> element (the output of the normalizer) does not handle $facility, this data is discarded.

The nested <node/> element shown in the following code fragment processes the <input> identified as a unit by the Rauland system and allows it if the unit begins with the literal VND and is followed by any of the numbers 1 through 4.

<node>
   <input>/location.unit</input>
   <pattern>VND[1-4]</pattern>
   <variables>$unit</variables>
   ...

Since our sample input unit meets this criterion, the node processes it and assigns the input directly to $unit, again without transforming it. As with $facility, the <format/> element does not handle $unit and the data is discarded.

The nested <node/> element shown in the following code fragment processes the <input/> identified as a room by the Rauland system. The ? quantifier (once or not at all) is necessary because Rauland sometimes sends a room as the string RM followed by a space and a three-digit number; other times, the Rauland system just passes the three-digit number.

<node>
   <input>/location.room</input>
   <pattern>(RM )?([0-9]{3})</pattern>
   <variables>$*,$1,$room</variables>
   ...

In the previous code snippet, the <pattern/> element comprises three regular expression groups:

The ([0-9]{3}) group allows a three-digit number, each digit of which can be any of the numbers 0 through 9. Our sample input RM 103 is allowed by the <node/> and the value 103 is assigned to the $room variable and passed to the <format/> output.

The final <node/> element, which is shown in the following code fragment, processes the <input/> identified as a bed by the Rauland system.

<node>
   <input>/location.bed</input>
   <pattern>[0-9]+</pattern>
   <variables>$bed</variables>
   </node>

The [0-9] part of the <pattern/> allows any single digit in the range of 0 through 9; the + quantifier (one or more times) is necessary because some beds in this system are multiple digit numbers. Our sample input 1 is allowed by the <node/> and the value 1 is assigned to the bed variable and passed to the <format/> output.

The processing for this <entry/> is complete, and the <format> element now evaluates to Room 103 Bed 1, transformed for CTS consumption from the original normalizer input of Vendor_Validation VND 1 RM 103 1.