Servigistics InService Publishing and Loading > Additional Information > TAL Overview > The TAL Process > TAL Process Internal Details
  
TAL Process Internal Details
IMAN supports a cascading notion of establishing object identity as well as ownership and priority of ownership. For example, parts published from SIM will be delivered in the artifact referencedParts.xml and each part will have a unique and persistent URI. When parts are delivered from SAP, they will not have a URI. IMAN handles the discrepancy by providing means to declare primary identifying attributes (such as a URI) as well as secondary attributes.
In the parts case, the secondary identifying attributes are composed of part number and orgName so the same part can be resolved regardless of its source using the business attributes. The IMAN design enables InService to either treat data from various systems (SIM and non-SIM ) on equal footing or to establish a priority where one system can either take precedence over data from the other system or take ownership of the data.
The process has the following stages:
Initialize – initialize the transformation process
For each type:
1. Prepare the identifying attributes XML for all objects based on IMANConfig.xml.
2. Pass the attributes XML to IMANManager using the IMANManager.identify() API.
3. The Transform Registry (TR) generates the Registry file for this type.
* 
Usually this step gets completed as a single transaction for all types during the start of TAL. If multiple bundles are getting loaded at the same time, then you must ensure synchronization. In the TAL flow, synchronized flows are invoked to ensure there is no data corruption. Otherwise, it is possible that same ID will be created for the same object and eventually lead to inconsistency and failure.
Transform:
1. Use the Transform Registry file generated above to identify what action (add, update, delete, or ignore) needs to be taken.
2. Populate the DCTM_Output folder.
Usually this folder is located at INSERVICE_WORK/DCTM_Output.
3. Generate the manifest file for records to be updated or deleted.
4. Update the TR with the updated publish date.
Validate – validate the data generated (as present in DCTM_Output) after the transformation process.
Load:
1. Trigger the Publish to Preview Preparation (P2PP) task to load the bundle.
2. At the end of P2PP, remove the validate lock applied on the bundle.