StateTransition Activity
The StateTransition activity defines a simple state machine that allows the workflow designer to build the business state of an enterprise across workflow and document types.
The states and transitions are defined in two separate tables, SupplierState and SupplierStateTransition, which must be fed with seed data, when the supplier is first connected to the service. The state machine operates on the implicit assumption that documents that logically belong together will all have one or more IDs in common, which identify the conversation they take part in. When a document that is already part of a conversation comes in, the workflow can use xpath expressions to get to the keys and lookup the current state of the conversation to which the document belongs. It can then move to a new state if appropriate or handle errors, if documents arrive out of order. Conversations are stored in the Conversation table, in which there will be one and only one record per conversation.
The state transition activity has two primary actions, ‘new’ and ‘join’. When the former is specified, the activity will create a new entry in the Conversation table based on a unique key and an initial conversation state, and thus initialize the supplier specific state machine for a new set of documents. The latter action allows the workflow designer to specify that a document should ‘join’ an existing conversation, and move to a new state. The new state to move to is specified in the ‘MoveTo’ parameter in the workflow, but the set of legal moves are defined in the SupplierStateTransition table. The key used to lookup the conversation must be unique for a set of documents across marketplaces, which means that at least some sort of DocumentID (for example, POID) and the marketplace ID or name is needed to ensure uniqueness. Since the exact keys needed is not known, the workflow designer can specify any number of key-parts (Key1, Key2, and so on), which will then be concatenated into one big key and used for lookup in the Conversation table. When joining a conversation you can specify a “NewKey” which will be added to the list of keys for this conversation. This is useful for bridging keys for long conversations.
If the state machine fails to move the transition, it will throw an exception if the out parameter ‘CouldMove’ is not specified. If the parameter is specified and an error occurs, ‘CouldMove’ will be false, otherwise it will be true. Another optional out parameter, ‘ConversationState’ will contain the current state of the current conversation after the state machine has attempted a move.