A Pipeline Component is a C# class that processes messages flowing through an Art2link ESB Pipeline. Each component receives a message, applies your logic, and returns one or more messages to the next stage of the pipeline.

Art2link ESB handles compilation and deployment automatically. You write the code, save it, and reference it from a Pipeline, no build steps, no restarts, no downtime.

The architecture follows a simple chain: Port → Pipeline → Component(s) → Output. A Pipeline can contain multiple components executed in sequence. Each component operates on the output of the previous one.

Two kinds of work happen inside a component. The obvious one is transformation, reshape the body, enrich it, compress, sign, validate. The other is classification: every message the component emits carries a Message Type, assigned by setting MessageType on the outgoing PipelineMessage. Classification is not a second power that only works one way. A component has no direction of its own, and neither does a pipeline. The words inbound and outbound describe the position a pipeline is attached at, not the artifact, and the typing rule is the same at every position. See Components classify the Message Type in the Pipelines article for the full contract; the code-level mechanics live in this reference.

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 component uses the same flow: with an Application selected, the editor opens with that Application preemptively chosen; without one, the form exposes an Application picker. Components are managed by the Application Owner and the Application Contributor, the same permission that governs every other artifact in the Application, no system-level role is involved.

The following classes are provided by the Art2link runtime in the CC.Art2link.Pipelines.Domain.Models.PipelineComponents namespace. Do not redefine them in your component code.

The incoming message passed to your component.

The result returned by your component after processing.

An individual outgoing message.

The abstract base class your component must inherit from. It handles JSON deserialization of the configuration and delegates to your ExecuteAsync implementation.

public abstract class PipelineComponentBase<TConfig>
    : IPipelineComponent where TConfig : new()
{
    public abstract string Name { get; }

    // Called by the engine, deserializes configJson, then delegates below
    public Task<PipelineComponentOutput> ExecuteAsync(
        PipelineComponentInput input,
        string configJson,
        CancellationToken cancellationToken = default) { ... }

    // Implement this method with your logic
    protected abstract Task<PipelineComponentOutput> ExecuteAsync(
        PipelineComponentInput input,
        TConfig config,
        CancellationToken cancellationToken);
}

The configuration class defines all user-editable parameters for your component. Each public property becomes an input field in the Art2link ESB UI when the component is added to a pipeline.

Any type that is JSON-deserializable by System.Text.Json is supported: string, int, bool, double, enum, List<T>, and complex objects.

When a configuration property is typed as an enum, Art2link ESB renders it as a dropdown in the pipeline UI instead of a free-text box. The options are the enum members, and the property’s default value is preselected. The operator picks from a fixed set rather than typing a string you then have to validate, which removes a whole class of typos.

Decorate the enum with [JsonConverter(typeof(JsonStringEnumConverter))] so the selected value round-trips by name. Without it, System.Text.Json serializes the enum by its integer value, which is harder to read in stored config and in {{ }} bindings.

using System.Text.Json.Serialization;

// Serializes by name ("Gzip" / "Deflate") rather than by integer
[JsonConverter(typeof(JsonStringEnumConverter))]
public enum CompressionMode { Gzip, Deflate }

public sealed class CompressorConfig
{
    // Renders as a two-option dropdown; Gzip is preselected
    public CompressionMode Mode { get; set; } = CompressionMode.Gzip;
}

Assign defaults directly on properties. These values are shown pre-filled in the UI when a user configures your component.

You may use attributes from the System.ComponentModel.DataAnnotations namespace to enforce constraints on configuration values.

using System.ComponentModel.DataAnnotations;

public sealed class MyComponentConfig
{
    [Required]
    public string TargetEndpoint { get; set; } = string.Empty;

    [Range(1, 10)]
    public int MaxRetries { get; set; } = 3;

    public bool IncludeHeaders { get; set; } = true;
}

Configuration values support the {{ }} binding syntax, letting users reference application Variables, application Constants, message-level promoted properties, custom functions, and the originating port name when configuring a component in the UI:

A pipeline component transforms the message it is given. Anything that varies from one message to the next is read from that message, input.Body, not carried in the component’s code or baked into a configuration default. The same compiled component should process a message from any partner, account, or document without an edit, even structural descriptors, like the transaction-set ID a 997 acknowledges, are read from the message rather than typed.

Configuration properties are for stable, deployment-level knobs, a delimiter set, a feature toggle, the name of a downstream message type, a timeout, values that are the same for every message and that an operator might tune per environment. Per-message data is read from input.Body instead. A config property’s default should be empty or neutral rather than a real value, so a missed setting fails loudly instead of running with the wrong one.

The test is reuse across partners: deploy the component once in its Application, point two partners at it, and it does the right thing for both because it reads who they are from the message. Reuse here means many partners and many messages through one component, not one component shared between Applications, which is not a thing the platform does.

Each component must override the Name property with a unique identifier. This name is used internally by the pipeline engine to locate and invoke your component.

Components must not throw exceptions. Instead, catch all errors and return a PipelineComponentOutput with Success = false, a descriptive ErrorMessage, and optionally the caught Exception.

When a component returns Success = false, the pipeline stops execution immediately. No subsequent components will be invoked.

protected override Task<PipelineComponentOutput> ExecuteAsync(
    PipelineComponentInput input,
    MyComponentConfig config,
    CancellationToken cancellationToken)
{
    try
    {
        // Your logic here
        return Task.FromResult(new PipelineComponentOutput
        {
            Success = true,
            Messages =
            [
                new PipelineMessage
                {
                    Body        = result,
                    MessageType = "MyMessageType"   // required on every message
                }
            ]
        });
    }
    catch (Exception ex)
    {
        return Task.FromResult(new PipelineComponentOutput
        {
            Success = false,
            ErrorMessage = ex.Message,
            Exception = ex
        });
    }
}

The shape of the Messages list governs what happens next. Two patterns matter:

Beyond returning a transformed body, a component has two side-effect channels into the surrounding integration. Both are written into the result your component returns.

Both channels are populated at the same time you build the result. This is the canonical return shape: two outgoing messages, each one typed, and one application variable written along the way. Copy it whenever you emit messages, whatever position the pipeline is attached at.

protected override Task<PipelineComponentOutput> ExecuteAsync(
    PipelineComponentInput input,
    MyComponentConfig config,
    CancellationToken cancellationToken)
{
    try
    {
        // Your logic here
        return Task.FromResult(new PipelineComponentOutput
        {
            Success = true,
            Variables =
            {
                ["lastProcessedDocument"] = "INV-1001",
            },
            Messages =
            [
                new PipelineMessage
                {
                    Body = acknowledgementResult,
                    MessageType = "AcknowledgementMessageType"
                },
                new PipelineMessage
                {
                    Body = businessResult,
                    MessageType = "BusinessMessageType"
                }
            ]
        });
    }
    catch (Exception ex)
    {
        return Task.FromResult(new PipelineComponentOutput
        {
            Success = false,
            ErrorMessage = ex.Message,
            Exception = ex
        });
    }
}

When you save a component, Art2link ESB compiles and deploys it automatically. There is no manual build step and no restart required. The new version takes effect immediately for every pipeline in the same Application that references the component, and for nothing outside it.