Under the application’s Message types, create the three types this flow routes on. A message type is a name plus a format, no schema required:

Promotions live on the message type, so add them while you are here. The send port’s parameters (Step 6) and the alert subject (Step 7) bind these values, and adapter parameters are plain strings: they bind {{…}} tokens but never evaluate a body path.

A failed order re-publishes payload intact, but promotions are type-qualified, so the exception type needs its own:

Three external parties, three 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.

Create the table and procedure in your database, the send port (Step 6) calls the procedure. The order number is the primary key, so the MERGE is idempotent, a replayed order updates instead of duplicating.

CREATE TABLE dbo.Orders (
    OrderNumber  VARCHAR(40)   NOT NULL PRIMARY KEY,
    CustomerId   VARCHAR(40)   NOT NULL,
    CustomerName NVARCHAR(200) NULL,
    Region       VARCHAR(20)   NULL,
    OrderTotal   DECIMAL(18,2) NOT NULL,
    Currency     CHAR(3)       NOT NULL CONSTRAINT DF_Orders_Cur DEFAULT 'EUR',
    ReceivedAt   DATETIME2     NOT NULL CONSTRAINT DF_Orders_Rcv DEFAULT SYSUTCDATETIME()
);

CREATE OR ALTER PROCEDURE dbo.UpsertOrder
    @OrderNumber VARCHAR(40),
    @CustomerId  VARCHAR(40),
    @OrderTotal  DECIMAL(18,2)
AS
BEGIN
    SET NOCOUNT ON;
    MERGE dbo.Orders AS tgt
    USING (SELECT @OrderNumber AS OrderNumber) AS src
        ON tgt.OrderNumber = src.OrderNumber
    WHEN MATCHED THEN
        UPDATE SET CustomerId = @CustomerId,
                   OrderTotal = @OrderTotal
    WHEN NOT MATCHED THEN
        INSERT (OrderNumber, CustomerId, OrderTotal)
        VALUES (@OrderNumber, @CustomerId, @OrderTotal);
END;

Under the application’s Maps, create the map. A map is not a file, it is a named resource stored in the platform, defined by its name and the two message types it sits between, both created in Step 1.

A sample WebOrder as the storefront posts it, the same payload Step 8 tests with:

{
  "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 WebOrder JSON arrives as a string, so the template matches / and parses it with parse-json(); from there fields are read with the ?key accessor, the result is built as a map{} and serialized back to JSON. The order number gets the SO- prefix every downstream tutorial expects, and the account manager’s address rides along for the order fan-out notification:

<xsl:stylesheet version="3.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <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:value-of select="serialize(
      map {
        'orderNumber': concat('SO-', string($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'
      },
      map { 'method': 'json', 'indent': true() }
    )"/>
  </xsl:template>
</xsl:stylesheet>

Create 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.) If you need to step away mid-setup, Save Draft keeps the port under just its name; a draft does not exist to the runtime until the required fields are filled in and the port is saved properly.

Open the adapter configuration (the button beside Adapter) and pair the port with the storefront credential, so every caller must present it:

Every API Listener in the environment shares one ingress URL, the read-only Url at the foot of the dialog, so the storefront never calls a port-specific address: the runtime decides which receive port a request belongs to from the App header, the Authentication, and any distinguishing headers (routing on a shared ingress covers the full rule). Declare both in the Headers table:

On the Publish step under the port’s Solicit stages, set Message Type Fallback to WebOrder, from Step 1.

On the Map step, set Map Assignment to Typed and add one row, selecting the map from Step 4:

Create a send port OrderToDatabase bound to the SQL Caller, paired with the OrderDbSql Authentication from Step 2. It subscribes on {{Message.MessageType}} == "Order".

The procedure from Step 3 needs three values out of the payload; its parameters go under Input Parameters, one key/value row each, binding the promotions defined on Order in Step 1:

On OrderToDatabase, set Exception Message Type, on the port’s General step, to OrderInsertFailed, from Step 1. If the insert exhausts its retries, the failed order re-publishes under that type, payload intact, and the promotion you defined on it carries the order number into the alert subject.

Add an O365 Mail send port OpsAlert subscribing on {{Message.MessageType}} == "OrderInsertFailed":

There is nothing to deploy, everything you configured is already saved and live, because Art2link applies changes immediately. To bring the flow online you start the send ports first, then the receive port: start OrderToDatabase and OpsAlert, then start WebshopOrders. Starting the subscribers before the producer means the Listener never accepts an order before the database send port is ready to receive it. (To take the flow offline, stop the receive port first, for the same reason.)

Before you test, set Tracking to Enabled + Body on every port the flow touches, WebshopOrders, OrderToDatabase, and OpsAlert. That records each run step by step with the message body, so you can walk a single order end to end in tracking and see the payload exactly as it was mapped and inserted.

POST the Step 4 sample WebOrder to the shared ingress URL, the one base URL every API Listener in the environment is hosted under (see routing on a shared ingress), and present the three things the Listener routes on: the App: AcmeOrders header, the Purpose: OrderIntake header, and the storefront’s API Authentication credential. Verify in tracking that the run shows the map and the insert; check the row landed with order number SO-10472.

Stop the database or post an order that violates a constraint, and confirm the operations mailbox gets the OrderInsertFailed alert and the run is available for replay.