Documentation for a newer release is available. View Latest

Generation

Overview

Generation occurs when a flo-lang based project is built using maven. This process interprets the DSL code that has been defined in MPS to generate the following artefacts:

  • Code - this is a full set of runnable (Java) code.

  • Documentation - this is an ASCII doc representation of the information provided in the DSL.

  • Test Cases - each path through the designed flows will result in a separate test case that can be used to verify it’s capability. These are generated in the form of BDD scripts (.story files). An IPF test harness is also provided to facilitate execution of these tests.

  • Visualisation - a number of artefacts, both SVG and graph orientated, are provided to allow visualisation of generated flows in other tools (predominantly the operational data store, or ODS).

Generational Unit

The generational unit is the 'Model'. This means that anything defined within a model will be generated as a single unit, and therefore exists as a single package. Anything generated within a model will be packaged together and hence deployed together. Let’s now consider what happens after we’ve modelled our process, and how we can use this to generate an IPF application.

Let’s assume we have a simple model containing a flow and a call to some example DSL component. This could be any of the components discussed in the <LINK TO CONCEPTS SECTION>[concepts] section, for example, an external domain call. When generation is invoked on this model, we’ll see a number of key elements created:

generation 1

Key Generated Elements

In the above image, we can see that there are four key things to be aware of during the generation process:

  • The ESB Classes - these classes collectively form the Akka Event-Sourced Behaviour, which serves as the engine orchestrating the processing of a flow as it receives various inputs throughout its lifecycle.

  • The Model Domain class - this class serves as the central interface for interacting with the IPF-modelled domain, and provides a set of methods that allow for the provision of everything the domain needs to function.

  • The Model Operations class - this class provides access to a number of behaviour related functions the domain provides (e.g. aborting the flow). It also provides access to the flow’s descriptor. The descriptor contains useful information about the setup of a flow and is therefore used by several other components that interact with flo-lang.

  • The Port classes - the generated flo-lang model adheres to hexagonal architecture principles, with the port classes representing the interfaces through which an IPF application interacts with the domain. As part of the generation process, each DSL component in the flo-lang model will define its own port, allowing the required business logic to be applied via an adapter implementation.

For brevity, only a selection of the most relevant generated artefacts have been included above. Among the many others, some notable examples include test stories and asciidoc files.