Transaction Properties

   Journey Manager (JM) The transaction engine for the platform.  |    System Manager / DevOps  |  All versions This feature is related to all versions.

Journey Manager allows you to view and create transaction properties, which represent arbitrary data as string objects. The main persistence model in Manager is an XMLXML (Extensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. file, which is stored on the server and sent to a browser when a form is rendered. It's then sent back to Manager after the form is submitted. It is also saved to the server in background save events.

There are situations when it is useful to store some information, which is not part of the XML file, on the server only. For example, you may want to record a user's actual credit score, but not show it to the user. In this case, you can store results from the back-end server calls and send only a pass or fail result to the form, so form users won't see their actual score or the reasons why they failed. You can also store in-progress data that has been used in the back-end service calls temporarily to ensure that form users don't "game" the system by changing the data in the form at different points of their journey.

Manager comes with the Unified Application Data Document Model that allows you to store integration data separately from a form data. This means that data, which should not be visible or accessible in a browser, is not stored in the AvokaSmartform tag in the XML. Instead, data is stored in the server xml node which remains accessible only on server-side.To achieve this, you need to enable the Unified App Data feature for a form version, which you can easily do while configuring the form version.

To view transaction's properties:

1. Select Operations > Form Transactions.
2. Locate a transaction and click View.
3. Select the Properties tab to see all properties pertaining to the selected transaction.
Note

This tab is only available if there are properties associated with the selected transaction.



4. Select a property and click View to see the property's value in a new browser tab.
5. Click Close.

Sometimes, you may want to add a new property to a transaction so it will be stored together. To add and store a transaction property, you should use the following Fluent Groovy API:

package exchange;

import com.avoka.tm.func.*
import com.avoka.tm.svc.*
import com.avoka.tm.util.*
import com.avoka.tm.vo.*
import javax.servlet.http.*
import com.avoka.tm.query.*

public class GetExchangeRate {

	// Injected at runtime
	public Logger logger

	/*
	* Perform Fluent Function call.
	*
	* returns: FuncResult
	*/
	FuncResult invoke(FuncParam param) {

		logger.info(param.txn.formStatus)

		new TxnUpdater(param.txn)
			.setProperty("PropertyA", "One")
			.update()

		FormFuncResult result = new FormFuncResult()

		logger.info("test log event")
		logger.debug("Debug log event")

		return result
	}
}

To retrieve transaction properties, you can use the Fluent Groovy code:

Txn txn = new TxnQuery()
	.setSubmitKey(…) // or similar to find the correct transaction
	.withPropertyMap() // to retrieve the properties
	.firstValue() //to find the first matching transaction
// The txn contains an attribute propertyMap of type Map<String,String>

When working with transaction properties, you should take into account the following:

• Data stored in the Transaction Properties are encrypted and subject to data retention policies, just like XML.
• In some cases, it may be necessary to store data against a collaboration job rather than an individual transaction.
• The PropertyQuery service is used for locating configuration properties for form versions, Workspaces, and so on. This is for static configuration properties, not for per-transaction or runtime properties.
• It is also possible to use the standard HTTP session to store temporary data. However, this data will not be persisted beyond an individual session. A transaction property is persisted in the database.

Next, learn about the transaction timeline.