Unified Application Data Document Model

   Journey Manager (JM) The transaction engine for the platform. |   System Manager / DevOps |  17.10 This feature was introduced in 17.10.

Journey Manager comes with the Unified Application Data Document Model that allows you to store integration data separately from a form data. This is the recommended approach as compared to the transaction properties.

The Temenos Journey Manager platform is essentially based on a document oriented architecture where we provide a seamless customer experience to capture data for further processing. During the application life cycle we persist application data in XML format that can be used to deliver data to the back end for customer onboarding. During the application process we also integrate with various third party to perform operations such as lookup, prefill, validation, authentication, authorization, funding, account onboarding and list goes on. These operations are executed on server side and responses may return back to application front end to perform next steps. End user may not need to see every single detail of the operation performed by the server, however it is important to persist the state and responses on the server for making decisions based on the outcome, or deliver to back-end for detailed outcome of those operations. So persisting that information becomes as critical as persisting user entered information.

In earlier days, developers persist server side information as Manager properties and use it for making a decision. These properties are saved as database entities against the transaction and available until transaction is purged. This is basically a key-value pair that can be retrieved by querying transaction property name.

Since Manager 17.10, you can enable the Unified Application Data Document Model mechanism in a form version by selecting the Unified App Data checkbox.

By default all transactions use AvokaSmartForm as the root node for transaction XML. Upon enabling this feature, Manager adds an additional wrapper called Root to AvokaSmartForm. During the form render request, Manager only sends or merges nodes under "AvokaSmartForm" and the rest of the information stays on the server. This allows the developer to persist all information that is not relevant or sensitive to the client on the server itself.

<?xml version="1.0" encoding="UTF-8"?>
<Root>
  <AvokaSmartForm>
    <Applicant>
      <FirstName>John</FirstName>
      <LastName>Doe</LastName>
    </Applicant>
  </AvokaSmartForm>
</Root>

When to use Unified App Data

Both Transaction Properties and Unified App data model allow the developer to persist server side information. Since there is no right or wrong approach but Unified App model was introduced to make the developer's life easier and serves many benefits over the conventional approach to save information as transaction properties such as:

• Data Integrity - It is important that application data is not manipulated by accessing form data JSON on client side. If we completely rely on form data, then there is a possibility that if someone intentionally try's to override the application outcome. Persisting data on server side XML allows developer to validate the information or use that information as a base for further processing rather than completely relying on data passed by front end.
• Data Marshaling - Manager provides APIs to allow developers to generate and populate VOs from XML structure. This allows developers to work with POJOs rather than arbitrary values. This helps to write better unit tests against various application states.
• Data validation - Data can be validated against XML Schema validation rules.
• Data Sensitivity - Critical information that doesn't need to be exposed will still be available on server by accessing transaction XML. Developer doesn't need to adopt any additional approach to persist anything beyond transaction XML.
• Data Delivery - Delivery API can deliver transaction XML which will automatically deliver the server side information to a customer where transaction properties require additional effort.
• Encryption - A transaction form XML data is always obfuscated in the database, while transaction properties are not. This protects against any PII data being exposed.

When you prefill the application or hydrate it with details like created account numbers, you should consider carefully what data to include in each tag because it goes to the browser. In most cases, you should only send masked values, not the raw ones. You should keep the raw values on the server-side only.

Springboard by default has some design patterns around this with the Lock Customer function, which you can use as a best practice.

When to use Transaction Properties

Transaction Properties and Unified App Data are not mutually exclusive. The developer can still use transaction properties for scenarios such as:

• Reporting - You may require a custom report on transaction data which becomes pain by parsing form xml for every transaction. A data extract or transaction property (as long as it doesn't contain PII) can be used to save the information that you can report on.
• Workspace - As at the time of writing this article, workspace API are designed to read transaction properties to display integration outcome / high level information on the screen. This is currently not designed to read form xml. There are plans to include form xml support in future.
• Immense data - There are some use cases where developer needs to persist huge amount of information (may be a raw response). This is still debatable but I personally don't feel to record immense amount of data as server xml, specially responses returned by 3rd party vendors as we don't know what the data format would be. Saving unknown information that may include unsupported xml values can lead into issues. This kind of information can persist as Transaction Property (blob) in the database.

Next, learn about the data model.