Under the application’s Message types, create the three types the two channels route on. A message type is a name plus a format, no schema needed; add one later only for validation:

No promotions are needed in this flow: the subscriptions route on the message type or the originating port, never on a payload field.

Two channels, two credentials. Under the application’s Authentications, the dialog asks for a Name, the Adapter it pairs with, and a Definition, the credential shape that adapter offers, with the Application preset; the Definition decides the config section that follows.

Under the application’s Maps, create channel one’s map. The webshop payload is JSON, so a map is the right tool: a map’s source must be JSON or XML, and this source is JSON. The map is defined by its name and the two types it sits between, both from Step 1. (Channel two’s CSV gets a pipeline component in Step 4, not a map.)

A sample WebOrder as the storefront posts it:

{
  "order_no": "10472",
  "ship_region": "EMEA",
  "buyer": { "ref": "C-2201", "company": "Nordwind Retail" },
  "account_mgr": "j.driessen@example.com",
  "grand_total": 1249.50
}

Maps are authored in XSLT 3.0 and run on Saxon HE 12.9. The JSON arrives as a string, so the template matches / and parses it with parse-json(); the result is serialized back to JSON, channel marker included:

<xsl:stylesheet version="3.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xsl:output method="text"/>

  <!-- The WebOrder JSON arrives as a string; parse-json() turns it into an XPath 3.1 map -->
  <xsl:template match="/">
    <xsl:variable name="in" select="parse-json(.)"/>
    <xsl:variable name="order" select="map {
      'orderNumber': concat('SO-', $in?order_no),
      'channel': 'webshop',
      'region': string($in?ship_region),
      'customer': map {
        'id': string($in?buyer?ref),
        'name': string($in?buyer?company)
      },
      'accountManager': map { 'email': string($in?account_mgr) },
      'total': number($in?grand_total),
      'currency': 'EUR'
    }"/>
    <xsl:value-of select="serialize($order,
      map { 'method': 'json', 'indent': true() })"/>
  </xsl:template>
</xsl:stylesheet>

Channel two’s file is CSV, which can never be a map source, so the parse belongs in a pipeline component. Under the application’s Pipeline components, create MarketplaceCsvDisassembler: it reads the raw CSV body, builds the same canonical Order JSON the webshop map produces (channel marker included), and classifies each emitted message as Order so the bus carries JSON. A file carrying many orders emits one message per row; the sample below carries one.

order_ref,buyer_company,buyer_ref,total,currency,region
MP-99021,Brams Outdoor BV,C-2201,412.00,EUR,EMEA

becomes the same canonical shape the webshop map produces, classified as Order:

{
  "orderNumber": "MP-99021",
  "channel": "marketplace",
  "region": "EMEA",
  "customer": { "id": "C-2201", "name": "Brams Outdoor BV" },
  "total": 412.00,
  "currency": "EUR"
}

using System.Text.Json;
using CC.Art2link.Pipelines.Domain.Models.PipelineComponents;

public sealed class MarketplaceConfig
{
    // No per-message values: the canonical shape is fixed by the marketplace layout.
}

public sealed class MarketplaceCsvDisassembler
    : PipelineComponentBase<MarketplaceConfig>
{
    public override string Name => "MarketplaceCsvDisassembler";

    protected override Task<PipelineComponentOutput> ExecuteAsync(
        PipelineComponentInput input,
        MarketplaceConfig config,
        CancellationToken cancellationToken)
    {
        try
        {
            // Read the raw CSV body the SFTP download handed in.
            var lines = input.Body
                .Split('\n')
                .Select(l => l.TrimEnd('\r'))
                .Where(l => l.Length > 0)
                .ToList();

            var messages = new List<PipelineMessage>();
            foreach (var line in lines.Skip(1))   // skip header row
            {
                var c = line.Split(',');
                var json = JsonSerializer.Serialize(new
                {
                    orderNumber = c[0],
                    channel     = "marketplace",   // channel marker
                    region      = c[5],
                    customer    = new { id = c[2], name = c[1] },
                    total       = decimal.Parse(c[3]),
                    currency    = c[4]
                });
                // Classify each message as the canonical type: the bus carries JSON, not CSV.
                messages.Add(new PipelineMessage
                {
                    Body        = json,
                    MessageType = "Order"
                });
            }

            return Task.FromResult(new PipelineComponentOutput
            {
                Success = true, Messages = messages
            });
        }
        catch (Exception ex)
        {
            return Task.FromResult(new PipelineComponentOutput
            {
                Success      = false,
                ErrorMessage = $"MarketplaceCsvDisassembler: {ex.Message}",
                Exception    = ex
            });
        }
    }
}

The fetch port in Step 8 cannot point at this component directly. It points at a pipeline, a named, ordered list of components that also carries the default values for each component’s configuration properties. Create one to hold the disassembler; MarketplaceConfig exposes no properties, because the canonical shape is fixed by the marketplace layout, so the pipeline is simply the named holder the port selects:

If the online order intake build already lives in this Application, skip this step: the channel below is that build. Otherwise create channel one now: a receive port WebshopOrders bound to the API Listener. Everything it references already exists, so each field is a pure selection. (The dropdowns can also create types and maps inline; building the dependencies first keeps each dialog a selection.)

In the adapter configuration, pair the port with StorefrontToken, from Step 2, so every caller must present it.

Declare the two matching headers that keep this Listener unique on the shared ingress (routing on a shared ingress covers the full rule):

Every receive port carries an Adapter Message Type, and it is required: the runtime stamps it the instant the Listener hands the posted body to the next step inside the port, so nothing travels untyped.

On the inbound side, select WebOrderToOrder, from Step 3, so the storefront’s payload publishes as the canonical Order.

Give the bus one observable consumer: a send port OrderSink with no adapter (a send port without an adapter), subscribing on {{Message.MessageType}} == "Order". It stands in for the downstream estate, the fulfilment, finance, and notification ports of the fan-out, so the convergence is visible in tracking even on an empty environment.

Create a receive port MarketplaceClock on the Scheduler:

Create a two-way SFTP Caller send port MarketplaceFetch, subscribing on {{Config.PortName}} == "MarketplaceClock", the clock from Step 7:

Set Authentication to MarketplaceSftp, from Step 2.

The downloaded file comes back on the port’s response side, which is an inbound position: the message is entering the bus there, so that side carries a required Adapter Message Type too. The raw CSV is typed the moment the SFTP Caller releases it, then MarketplaceImportPipeline, from Step 4, runs the MarketplaceCsvDisassembler it holds, which splits the file and states Order on each message it emits. The component re-typing the message is not a special case, it is the rule: every message a component returns carries the type the component puts on it. There is no map on this channel, because the CSV could not be a map source.

This step is the point: do not create or modify any downstream port. Every subscriber on {{Message.MessageType}} == "Order" serves the new channel as-is: the OrderSink stand-in from Step 6 today, the fulfilment, finance, and notification ports of a real estate tomorrow.

The webshop channel keeps its order-intake API Listener unchanged, App and Purpose headers and all, because the new channel arrives over SFTP, not the shared API ingress, so there is no Listener to make unique here.

Turn on Activity Notifications for the Application (On Error Only). A payload that fails on either channel suspends at its own edge and emails the team: a webshop payload that will not map, or a marketplace CSV the disassembler component cannot parse. The original payload is held in tracking for Resume.

Everything you configure is live the moment you save it, there is nothing to deploy. Start the send ports first, OrderSink and MarketplaceFetch, then the receive ports WebshopOrders and MarketplaceClock.

Set the Application’s tracking level to Enabled + Body so you can walk each run step by step, with its message body. Tracking is an Application-level setting, so this one choice covers every port the flow touches, and you can drop it back to Only on Error once the flow is proven.

Run one order through each channel, a webshop POST and a marketplace CSV fetch. To test the fetch without waiting for the daily window, temporarily set MarketplaceClock to repeat every 1 Minutes, then restore the schedule. What you should see: the fetch run in tracking shows the download, the MarketplaceCsvDisassembler turning the CSV into JSON, and one canonical Order published to the bus.

In tracking, both runs converge on identical Order publications and identical downstream deliveries; only the channel marker differs. That equivalence is your acceptance test for the canonical model.