Pipelines
A reusable, ordered group of custom pipeline components - assembled once, referenced by ports, configurable in place.
A pipeline is a named, ordered list of custom pipeline components, bundled so a port can reference the whole sequence by name instead of wiring components one at a time. The pipeline carries default values for every property its components expose, and any port that references the pipeline can override those defaults in place.
That is the entire shape of the concept. There is no fixed BizTalk-style chain of decoder → validator → transformer → encoder, no inbound-vs-outbound type, no built-in stages - just an ordered list of components, the defaults you want for them, and the ports that pull them in.
In BizTalk a pipeline is a fixed-shape object - receive or send, with named stages (Decode, Disassemble, Validate, ResolveParty…) that components plug into. Art2link ESB does not work that way. A pipeline here is a flat, ordered list. The components run in the order you put them; nothing else is implied by their position.
The work of choosing where a pipeline runs has been moved up to the port. A port has named stages, and one of those stages is "pipeline" - either inbound or outbound, depending on direction. The pipeline you attach there is the same kind of object regardless of stage; it is the port that gives it a role.
Pipelines are scoped to an Application. From the application menu, the Pipelines list shows every pipeline you have defined inside that application. Each entry has just a few fields:
| Field | Purpose |
|---|---|
| Name | How the pipeline is referenced when a port attaches it. Unique within the application. |
| Components | The ordered list of custom pipeline components that make up the pipeline. The order is the execution order. |
| Default property values | For each component's configuration properties, the value the pipeline supplies as the default. Ports inherit these and may override any of them. |
A pipeline itself is per-Application: two Applications cannot share a pipeline, and if the same processing is needed in both, define the pipeline in each. The components a pipeline references are different - they live at the system level (see Custom pipeline components), so any pipeline in any Application can reference any component, and changes to a component's code propagate to every pipeline that uses it regardless of which Application owns the pipeline.
The list view follows the platform's Selected Application behavior - with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to and the column is shown. Creating a new pipeline uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker.
The body of a pipeline is the list of components it contains, in the order they should run. Each entry references a custom pipeline component by its Name. At runtime the components execute in sequence: each one receives the output of the previous one, applies its logic, and hands the result down the line.
A pipeline can contain a single component or many. The same component can appear in any number of different pipelines - pipelines are groupings, not owners, and components live independently of any particular pipeline.
Every custom pipeline component exposes its public configuration properties to the UI - see Configuration Class in the component reference. Those properties resolve in three tiers, weakest to strongest:
| Tier | Source | Effect |
|---|---|---|
| 1. Component default | The value assigned in the component's C# config class. | The starting point. Used when nothing further is set. |
| 2. Pipeline default | The value set on the property when the component is added to the pipeline. | Overrides the component default. This is what every port inherits when it attaches the pipeline. |
| 3. Port override | The value set on the property in the port that references the pipeline. | Wins. Applies only to that port. |
When a port references a pipeline, the port's UI surfaces every property of every component in that pipeline, prefilled with the pipeline's default values. Edit any of those values in place to override them - the change applies only to the port doing the override; other ports referencing the same pipeline are untouched.
A pipeline only ever executes because a port attached it to one of its stages. There is no standalone "run a pipeline" trigger. The four points where a pipeline can be attached are:
| Port type | Stage | Direction |
|---|---|---|
| Receive port (request side) | Inbound pipeline - stage 3 | Inbound |
| Receive port, two-way (response side) | Outbound pipeline - stage 3 of the response | Outbound |
| Send port (request side) | Outbound pipeline - stage 3 | Outbound |
| Send port, two-way (response side) | Inbound pipeline - stage 3 of the response | Inbound |
The pipeline is optional at every one of those points; if a port leaves it unset, the message bypasses the pipeline stage entirely. For the full numbered stage model and its diagrams, see Ports.
When a custom pipeline component referenced by a pipeline is edited and saved, every pipeline that uses it picks up the new code immediately - and so does every port that references those pipelines. There is no pipeline rebuild step, no redeploy, no host restart.
This works because Art2link ESB compiles components automatically on save (see runtime model in the component reference). The pipeline holds a reference to the component by name, not a frozen copy of its compiled output, so the next message through the pipeline runs against the latest version.
That is the whole job
An ordered list of components, the default values you want for them, and the ports that pull them in. Everything else - direction, stages, lifecycle - lives at the port and the component.