Journey Manager (JM) Previously known as Transact Manager (TM). | 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 Journey 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
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>
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:
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.
Transaction Properties and Unified App Data are not mutually exclusive. The developer can still use transaction properties for scenarios such as:
Next, learn about the data model.