Integration Model Editor: Difference between revisions
m (→UoP Instances) |
|||
Line 32: | Line 32: | ||
*'''Sources''' / '''Sinks''' have only one port. These represent elements that simply produce or consume Views. | *'''Sources''' / '''Sinks''' have only one port. These represent elements that simply produce or consume Views. | ||
* '''Transforms''' consume one type of View and produce another. The Node Inspector is used to adjust settings. Notably, the Transform type is used to change from | * '''Transforms''' consume one type of View and produce another. The Node Inspector is used to adjust settings. Notably, the Transform type is used to change from | ||
** Automatic transform that draws on semantic and measurement information to mediate between the two Views: | |||
[[File:Imeditor - AutoTransform.png|none|thumb|221x221px]] | [[File:Imeditor - AutoTransform.png|none|thumb|221x221px]] | ||
** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code: | |||
[[File:Imeditor - ManualTransform.png|none|thumb|282x282px]] | [[File:Imeditor - ManualTransform.png|none|thumb|282x282px]] | ||
Revision as of 13:07, 23 July 2024
The Integration Model (IM) Editor is a groundbreaking new region of PHENOM that combines visualizations with direct model editing.
The Integration Model is perhaps the most important model of them all. It provides a representation of how your UoPs and communication channels are laid out in the physical world.
A well-designed IM is what allows us to generate a fully configured CinC transport layer.
UoP Instances
UoP Instances are, as the name suggests, instantiated Units of Portability. They can be created from the IM Editor or from the 'Create' dropdown in regular Navigate mode.
Each one is given a name and a Configuration URI (optional). You are also expected to select some subset of the UoP's Connections to use as Endpoints in the UoP Instance.
Transport Channels
A Transport Channel holds information required to transmit across some outside channel.
Currently UDP channels are supported.
At the moment, you are expected to use the description field to populate the following comma-separated values: ip, local port, destination ip, destination port, ttl.
Integration Contexts
This is where we find the real meat and potatoes of your integration situation. A Context is a graph representing the flow of DataTypes, or Views, amongst UoP Instances.
A given context can pull in the items discussed above. In fact, a given UoP Instance might be used in multiple Contexts. The different Contexts simply illustrate different aspects of the layout.
The IM Editor lets you work on one Context at a time. First, drag and drop to insert a UoP Instance. (Technically, the UoP Instance exists outside the Context, but since it's connected to things inside, it will be useful to have it here).
Transport Nodes
Transport nodes come in several flavors which can be created by dragging and dropping from the Stencil tool on the left-hand side.
Once placed in the Context, the Node Inspector on the right-hand side is used to give the nodes names, descriptions, and other data specific to its type.
- Sources / Sinks have only one port. These represent elements that simply produce or consume Views.
- Transforms consume one type of View and produce another. The Node Inspector is used to adjust settings. Notably, the Transform type is used to change from
- Automatic transform that draws on semantic and measurement information to mediate between the two Views:
- Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:
- Filters require a 'Test' field that will filter out Views for which the test evaluates to False.
- Transporters allow you to select a Transport Channel to transmit across.
- Fanins allow for several input connections and only outputs one type.
- Generics can have any number of input or output connections.
- SIM Adapters for Single Instance Messaging communication style.
- Queuing Adapters for Queuing communication style.
- Data Pumps periodically poll the previous block to move messages forward.
The Adapter blocks allow interoperability when the UoP Message Port is expecting a certain kind of communication style.
Connections
Connections are created by dragging from an output port to an input port:
If the data types are inconsistent then the connection will turn red and you won't be allowed to save. In this situation, we have a UoP Instance node outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
Ports
Ports facilitate the type that is used during context node connections and can be either input or output endpoints. Ports can accessed from the Node Inspector on the right-hand side when selecting a node with ports. All ports have rolename, flowtrigger, type, and a special identifier field depending on which type is selected. Additionally, ports can be dragged around a context nodes border from within the context.
There are two views when editing a ports Type:
a) Default & Data Type
Data Type must be given from an existing view type from the model.
b) Templated & Template type
Template type must be typed into the input and is determined by the user.
Composed Block Integration Contexts
The composed block integration context is a special kind of context that can be nested inside another context of any type, treating it as a context node via a composed block instance.
Any high-level context can include a composed block instance to simplify complex modeling and connections. This setup lets viewers understand the overall flow without getting overwhelmed by the modeling details held within the composed block context.
Switching an Integration Context to Composed
A context can be switched from normal to composed from the context tab from within the side panel. Once switched, the context will behave just like a normal context but obtain a blue border and allow access to the composed ports.
Composed Ports
From within the composed block context, the user may drag in any number of Composed In/Out port nodes. The composed ports nodes have only one respective input/output port and can be connected to the other context nodes. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).
These composed port nodes are identical to the ones utilized by a composed block instance.
Composed Block Context Instances
After the user is finished creating their composed block context and either saves or commits it, the composed block context can be seen in the NavTree and is ready to be dragged in as an instance to another context of any type.
Once dragged in, it behaves like the other context nodes and can be connected to any of the other nodes and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
Code Generation
CinC generation targets a different type of element called a Main Program. These are created from the main 'CREATE' dropdown.
Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.
Similarly, Main Programs can be placed in Processing Elements - but these are not incorporated into generation yet.