The integration begins where the order does, at the endpoint the webshop posts to. Under the application’s Ports, create a receive port bound to the API Listener. Nothing it needs exists yet, and that is fine: each field below creates what it references on the spot. If you have 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). The first thing it asks for is the credential every caller must present. Nothing is there yet, so create it right here at the Auth Config field; the dialog opens on top of the port and returns you to it when you save:

The token is a shared secret: whatever you type here is what the webshop (and in Step 6, Postman) has to send on every call. The example above is fine for the tutorial; for a real storefront generate a long random value and hand it to the webshop team through a secrets channel, never by email.

Back in the adapter configuration, finish the rest:

Back on the port’s General tab, one row of the table above is still open, the required Adapter Message Type. The runtime applies it the instant the Listener releases the body, so the message is typed before anything else runs. The storefront’s shape has no type yet, so create it here at the field. A message type is a name plus a Format, no schema required, and it can hold a sample of the payload. Paste the sample below into Sample data: it has no runtime effect, but it documents the shape for whoever opens the type later, and it is the same payload you will post in Step 6.

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

Saving the type returns you to the port with Adapter Message Type now reading WebOrder, which completes the General table above. Leave the port open; the next step continues on its Map step.

Still inside WebshopOrders, go to the Map step and set Map Assignment to Typed. Add one row and, at its Map field, create the map. A map is not a file, it is a named resource defined by its name and the two message types it sits between:

The target does not exist yet either, so create it from the Target field. This is the shape the rest of the business reads, and the three values the SQL send port binds in Step 4 are lifted out of it by promotions. A promotion is a named path into the payload (JPath for a JSON type), so before naming any, look at the payload the map will produce:

{
  "orderNumber": "SO-10472",
  "channel": "webshop",
  "region": "EMEA",
  "customer": { "id": "C-2201", "name": "Nordwind Retail" },
  "accountManager": { "email": "j.driessen@example.com" },
  "total": 1249.50,
  "currency": "EUR"
}

Paste that JSON into the type’s Sample data first. Then, for each promotion, add a row, open its ellipsis menu and choose Generate Path: it shows the sample, you click the node you want, and the JPath is written for you. Click orderNumber and you get $.orderNumber; click the id inside customer and you get $.customer.id. You can also type the paths by hand, but the tool removes the guesswork on deeper shapes.

Adapter parameters are plain strings: they bind {{…}} tokens such as {{Promoted.Order.OrderNumber}} but never evaluate a body path themselves, which is why the promotions have to exist on the type. Save the type; you are back in the map with both types selected.

Now the map body. You do not have to write it by hand. Open the AI Accelerator, describe the translation in plain language, and let it generate the XSLT for you to review and paste into the map. It knows how iQBus maps read JSON and how to line fields up by meaning, but it sees nothing of your Application: not the message types you just created, not the promotions, nothing but the text you give it. So the prompt carries everything the map needs: the WebOrder sample, the Order sample, and the paths the promotions read. A prompt like this is enough:

Build a map from a JSON message type named WebOrder to a JSON message type named Order.

Match the storefront fields to the canonical order by meaning: the order number, the shipping region, the buyer's reference and company name as the customer's id and name, the account manager's email address, and the grand total as a number. Prefix the order number with SO- so it reads SO-10472. Add two constant fields, channel set to webshop and currency set to EUR. Three paths must be exactly $.orderNumber, $.customer.id and $.total, because promotions read them. Output indented JSON.

The WebOrder source looks like this (yours will carry different values but the same shape):

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

The Order target must look like this:

{
  "orderNumber": "SO-10472",
  "channel": "webshop",
  "region": "EMEA",
  "customer": { "id": "C-2201", "name": "Nordwind Retail" },
  "accountManager": { "email": "j.driessen@example.com" },
  "total": 1249.50,
  "currency": "EUR"
}

The AI Accelerator writes a first draft, not a finished map, so test it before you rely on it. The map editor has a tester built in: paste the sample WebOrder as the input, run the map, and compare the result with the Order sample above. What has to match exactly is the three promoted paths, $.orderNumber, $.customer.id and $.total; field order and formatting may differ, because the Accelerator does not return the exact same result twice. If you would rather start from working code, expand it here to read or copy.

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

Save the map, and the row on the port’s Map step reads:

Save the port. WebshopOrders is complete, stopped, and waiting; it goes live in Step 6.

The order database is the system you are integrating with, not part of iQBus, so it is set up by hand rather than asked of the AI Accelerator. Create the table and the procedure the send port calls in Step 4. 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 Ports, create a send port bound to the SQL Caller. Rather than being told what to deliver, a send port states which messages it wants; this one subscribes to every canonical order the receive port publishes.

Open the adapter configuration. At the Auth Config field, create the database credential in place, exactly as you did for the storefront token:

The SQL Caller connects from where iQBus runs, so two things decide the string: how iQBus reaches the server and how the server identifies iQBus. Reachability first: an Azure SQL database on a public endpoint needs iQBus’s outbound address allowed through the server firewall; one behind a private endpoint has to sit in, or be peered with, the iQBus network; an on-premises SQL Server is reached over a VPN or ExpressRoute link, and its hostname has to resolve from the iQBus side. Then the identity, which is what the two strings differ in. iQBus supports SQL authentication and managed identity; it does not support Entra ID interactive sign-in, and putting an Entra account’s username and password into a connection string is strongly discouraged, so neither appears here. Replace the placeholders in angle brackets with your own values:

For an on-premises server, swap the Server= value for its hostname or IP and port and use SQL authentication. For this tutorial, SQL authentication against a database whose firewall lets iQBus in is enough. Whichever you pick, the login needs EXECUTE on dbo.UpsertOrder.

Back in the adapter configuration, set the command and its parameters together. The procedure from Step 3 takes three values, one key/value row each, bound to the promotions you defined on Order in Step 2:

Save the port.

The storefront already has its acknowledgement by the time the insert runs, so a database failure is an internal recovery task, not a lost order: the run is recorded as failed in tracking with the order payload intact. Someone still has to hear about it. For this first tutorial the simplest way is an Activity Notification, a per-Application email subscription that fires on failed runs. Under the application’s Activity Notifications, create it:

There is nothing to deploy, everything you configured is already saved and live, because iQBus applies changes immediately. To bring the flow online you start the send port first, then the receive port: start OrderToDatabase, then start WebshopOrders. Starting the subscriber 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.) Tracking is already Enabled + Body from the Application, so every run you make now is recorded step by step with its payload.

We use Postman to stand in for the webshop; any similar HTTP client (Insomnia, Bruno, curl) works the same way. Install it, sign in or skip the account, and create a new request (New → HTTP). Fill it in from the values you set in Step 1:

Headers go on the Headers tab, one row each; the body on the Body tab with raw selected and JSON picked in the dropdown beside it. Save the request as Acme webshop order so you can send it again later.

Click Send. A success status comes back as soon as the message is on the bus; the acknowledgement means iQBus has the order, not that the row is written yet, that happens a moment later on the bus’s own time. Then open Tracking, find the run, and step through it, opening each message body as you go:

Finally check the database itself: SELECT * FROM dbo.Orders WHERE OrderNumber = 'SO-10472' returns one row. Send the same request again and the row count stays at one, that is the MERGE doing its job.

Stop the database, or change the request’s order_no to a value longer than 40 characters so the insert violates the column, and send again. The call still succeeds, the order is on the bus, but the run fails at the SQL Caller after its retries. Confirm the operations mailbox gets the OrderIntakeErrors email from Step 5, and that the failed run sits in tracking with the order payload intact, available for replay once the database is back.