Processing Modeling and Variation

The heart and soul of any business application lie in its business process models. A model, within the context of a Platform module, consists of data fields, workflows, declarative user interfaces, and state machines which together are designed to create a single, authoritative definition of a persistent business model from which all other run-time artifacts are generated. Models are defined in Studio and based on these models, artifacts such as Java classes, database DDL, XML schemata, and integration points are all generated automatically. When you make a change to a model, these artifacts are updated in synchronization with that model. The figure below summarizes what goes into a model and what is subsequently generated.

Figure 1.3. Models are defined using a graphical interface in Studio. From the model comes many of the files you would normally be creating and maintaining by hand as a developer.

Once a model is defined, Studio also allows for Process Variation on the model. This means you can create significant configuration changes to business processes for each model with little to no code changes. Each model can be deployed multiple times with process variations such as:

• Views—Models can contain variations in the way data is displayed without modifying the model's definition. Views have their own granular permissions models and a built-in user interface component. They represent a quick and easy way to display list / detail pages that might vary slightly or drastically from partner to partner within an application. Since the views are configurable independently of the model definition, there is no need to create multiple copies of a model to support different process variations from multiple trading partners.

• Actions—Centralized business actions for initiating changes to Models. Actions control how models are persisted. They feature transactional support so if any part fails, the model's state is rolled back to its previous condition. Actions work closely with the next two features.

• State Machines—Models allow for variations in the way states are processed. The states represent the life cycle of a model from its creation until its natural completion. For example, an order from a supplier might begin its life with a state called 'Created', followed by 'Shipped', 'Received', and finally 'Closed'. If you were to on-board a different supplier that requires verification of receipt for expensive or regulated items, you could create a second state diagram containing the additional states to cover just the supplier. This is done without modifying the business model.

  Figure 1.4. Example screenshot of a state machine diagram. Each state is connected in the diagram with named lines that dictate which states are possible from the current state. You can learn more about configuring state machines in the Chapter titled Data and Process Modeling with Studio

• Workflows—configurable hooks invoked during Action processing, allowing for the introduction of notifications, computations, integrations, and more. Actions, as we mentioned earlier, are configurable transaction wrappers that allow processing and ultimately the persistence of models. Workflows allow you to fine-tune the steps between the beginning of the transaction and the ultimate persistence. If we take our earlier example, our new supplier requires a receipt notification once we receive an item from a list of items that might be regulated. You could create a workflow that generates a notification automatically when a particular Action is processed. Additionally, workflows can perform validations, raise issues, compute aggregate data based on the inbound transaction, update related records, etc.

  Figure 1.5. A sample workflow showing an issue computation. You can learn more about workflows in the chapter titled Data and Process Modeling with Studio
  
  

The Process Modeling and Variation services in a Platform instance are responsible for managing and processing the models with their variations based on data they receive through the user interface or from integration points.