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
            });
        }
    }
}

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):

Set Message Type Fallback to WebOrder, from Step 1.

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.

In the port’s inbound flow, set Message Type Fallback to MarketplaceOrders, from Step 1, so the raw CSV carries a type, then reference the MarketplaceCsvDisassembler component, from Step 4, in the inbound flow. The component emits the canonical Order JSON and classifies it as Order; 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 Tracking to Enabled + Body on every port the flow touches, so you can walk each run step by step, with its message body, in tracking.

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.