We have discussed forms that allow users to interact with an application and we have discussed the data model that holds a history of those interactions so now is the time to join those two models together. This is where actions come in to play as these define what the application does in response to a user request.
Application actions follow a set of sequential steps based upon the input that they receive and then provide an output once completed. For instance within a policy administration system a ‘GetQuote’ action will take some risk data as input then perform a number of calculations based on that data to obtain a premium that is then output from the action. However these actions can be far more complex than that and often involve interactions with third party applications as well as being used to generate emails and other messaging services. To clearly specify the behaviour of an action you need to define:
- Inputs to the action
- The action steps including any business rules that determine if that step is required
- Outputs from the action
Inputs
The inputs to an action tend to the more technical aspects of an application and consequently are not that relevant to the logical design of the application. Typically there are two models that might be employed. These are a tightly coupled application design and a loosely coupled application design. Where the application design is tightly coupled then the data needed by the action is input directly. Where it is loosely coupled then only the data needed for the action to be able to look up the required data to complete the action is input. There are potential performance implications of both options based on the underlying architecture however from a logical perspective the most effective approach is to pass the minimum amount of data to an action and then let the action retrieve any other parts of the data model that it needs to manipulate. If you consider a website design then this is the typical approach. So when navigating from one web page to the next then the key data passed through is the URL that includes additional identifiers that can be used to retrieve the data needed for the next page in a ‘Get’ action. Where a more tightly coupled approach is required then session data is used to maintain this information.
The fields that are used as inputs for actions are always defined in the context of the underlying static data model. This allows the action to be called from both a form, another action or from a batch job, API or diary event. Should the interfacing fields be coupled to the form instead then the action is far less useful as it can only be used from the form that holds the particular display field used as input.
For each field required to input the action you need to know:
- Static model Data field
- Mandatory/Optional and rule to determine of the field is required
Processing
The diagram shows the relationship between an action and the other components in the logical data model.
The easiest way to define the behaviour of an action is in sequential steps. Each of these steps may have a business rule to determine if it is required and how many times it should be performed. Each of these steps will then perform one of the following:
- Use a service or interface to interact with a third party application.
- Send an email or other message such as an SMS or MMS.
- Create a document such as a certificate or letter.
- Create a diary event for later processing.
- Perform another action.
- Interact with the static model (e.g. to persist the input data or update the model).
Outputs
At a minimum an action should provide a return code to state if the performed action was successful or not. Where it was not successful then an error code should inform the calling logical model component what went wrong so that they can take the appropriate action. In addition to this functionality the business analyst should also specify the attributes and entities of the static data model that are returned by the action and any rules that determine whether or not they are returned.