Integration Model Editor: Difference between revisions
| (2 intermediate revisions by 2 users not shown) | |||
| Line 25: | Line 25: | ||
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). | 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). | ||
=== | === Processing Blocks === | ||
Processing blocks 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 Block Inspector on the right-hand side is used to give the blocks names, descriptions, and other data specific to its type. | |||
[[File:Imeditor - Sidepanel2.png|none|thumb|915x915px]] | |||
*'''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 | * '''Transforms''' consume one type of View and produce another. The Block 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: | ** Automatic transform that draws on semantic and measurement information to mediate between the two Views: | ||
[[File:Imeditor - AutoTransform.png|none| | *: [[File:Imeditor - AutoTransform.png|none|200px]] | ||
** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code: | ** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code: | ||
*:[[File:Imeditor - ManualTransform.png|none|200px]] | |||
* '''Filters''' require a 'Test' field that will filter out Views for which the test evaluates to False. | * '''Filters''' require a 'Test' field that will filter out Views for which the test evaluates to False. | ||
| Line 50: | Line 48: | ||
Connections are created by dragging from an output port to an input port: | Connections are created by dragging from an output port to an input port: | ||
[[File:Imeditor - Connection1.png|none|thumb|678x678px]] | [[File:Imeditor - Connection1.png|none|thumb|678x678px]] | ||
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 | 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 block outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes: | ||
[[File:Mismatched.png|none|thumb|511x511px]] | [[File:Mismatched.png|none|thumb|511x511px]] | ||
=== Ports === | === Ports === | ||
Ports facilitate the type that is used during context | Ports facilitate the type that is used during context block connections and can be either input or output endpoints. Ports can accessed from the Block Inspector on the right-hand side when selecting a block 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 blocks border from within the context. | ||
There are two types of ports: | There are two types of ports: | ||
| Line 68: | Line 66: | ||
== Composed Block Integration Contexts == | == 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 | 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 block 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. | 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. | ||
| Line 77: | Line 75: | ||
=== Composed Ports === | === Composed Ports === | ||
From within the composed block context, the user may drag in any number of Composed In/Out port | From within the composed block context, the user may drag in any number of Composed In/Out port blocks. The composed ports blocks have only one respective input/output port and can be connected to the other context blocks. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType). | ||
These composed port | These composed port blocks are identical to the ones utilized by a composed block instance. | ||
[[File:Imeditor - trimmedComposedPort1.png|none|thumb|794x794px]] | [[File:Imeditor - trimmedComposedPort1.png|none|thumb|794x794px]] | ||
| Line 85: | Line 83: | ||
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. | 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 | Once dragged in, it behaves like the other context blocks and can be connected to any of the other blocks and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context. | ||
[[File:Imeditor - ComposedInstance.png|none|thumb|831x831px]] | [[File:Imeditor - ComposedInstance.png|none|thumb|831x831px]] | ||
Latest revision as of 14:25, 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).
Processing Blocks
Processing blocks 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 Block Inspector on the right-hand side is used to give the blocks 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 Block 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 block outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
Ports
Ports facilitate the type that is used during context block connections and can be either input or output endpoints. Ports can accessed from the Block Inspector on the right-hand side when selecting a block 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 blocks border from within the context.
There are two types of ports:
a) Data Type
Data Type must be given from an existing view type from the model.
b) Template type
Template type 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 block 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 blocks. The composed ports blocks have only one respective input/output port and can be connected to the other context blocks. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).
These composed port blocks 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 blocks and can be connected to any of the other blocks and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
