New integrations, from a description.
You describe the flow in plain language. It drafts the pipeline component, selects adapters, drafts the mappings and generates tests.
Reach for it when: nothing exists yet
Tell the Accelerator what systems need to communicate. It drafts the pipeline — adapters selected, mappings drafted, tests generated — and your team reviews, adjusts and ships it. The draft is real code in your repository, not a black box you have to trust.
See the whole platformThe draft names the receive and send adapters the described flow actually needs, from the 200+ in the catalogue.
Transformations are written to the canonical schema you point at, so the shape is right before a human opens it.
The draft arrives with tests, so the first question after “does it compile” already has an answer.
The Accelerator is deployed inside your own Azure subscription. It reads only what you paste into it.
These are three real prompts and the three components they produce. Watch what happens at the end of each: the builder decides the output shape — whether one message becomes many, a batch fans out, or one goes in and one comes out. That decision is the difference between text completion and understanding an integration.
Take an HL7 lab order, disassemble it into canonical JSON, then split the batch into one message per order.
PipelineComponentOutput.Split()
One inbound batch becomes many independent messages, each routed and tracked on its own.
public sealed class Hl7LabOrderSplitter
: PipelineComponentBase<Hl7Config>
{
public override string Name => "fnHl7LabOrderSplitter";
// Disassemble the HL7 batch, then split per order
protected override async Task<PipelineComponentOutput> ExecuteAsync(
PipelineComponentInput input, Hl7Config config, CancellationToken ct)
{
var json = Hl7.Disassemble(input.Body, config.CanonicalSchema);
var orders = json.SelectTokens("$.orders[*]");
return PipelineComponentOutput.Split(orders);
}
}
Build a pipeline component that decodes a Base64 string, debatches the EDI interchange, and disassembles each transaction based on its EDI type.
PipelineComponentOutput.Many()
A mixed interchange fans out into typed transactions, each disassembled against its own schema.
public sealed class EdiDebatcher
: PipelineComponentBase<EdiConfig>
{
public override string Name => "fnEdiDebatcher";
// Decode, debatch the interchange, disassemble by EDI type
protected override async Task<PipelineComponentOutput> ExecuteAsync(
PipelineComponentInput input, EdiConfig config, CancellationToken ct)
{
var raw = Convert.FromBase64String(input.AsString());
var interchange = Edi.Debatch(raw);
var messages = interchange.Select(tx => Edi.Disassemble(tx, tx.DetectType()));
return PipelineComponentOutput.Many(messages);
}
}
Take a bank wire, decrypt it with the provided key parameter, check its fields, and forward on success or throw on failure in one component.
PipelineComponentOutput.Single()
One message in, one message out — and a hard failure rather than a silent drop when validation fails.
public sealed class BankWireGate
: PipelineComponentBase<WireConfig>
{
public override string Name => "fnBankWireGate";
// Decrypt with the key parameter, validate, forward or throw
protected override async Task<PipelineComponentOutput> ExecuteAsync(
PipelineComponentInput input, WireConfig config, CancellationToken ct)
{
var wire = Crypto.Decrypt(input.Body, config.KeyParameter);
if (!Wire.IsValid(wire, out var error))
throw new PipelineException(error);
return PipelineComponentOutput.Single(wire);
}
}
The usual objection to AI in an integration platform is the only one that matters: what leaves the building. The answer here is architectural rather than contractual.
Both are part of the AI Accelerator, and teams mid-migration usually run them side by side. They answer different questions, so it is worth knowing which one you are reaching for.
You describe the flow in plain language. It drafts the pipeline component, selects adapters, drafts the mappings and generates tests.
Reach for it when: nothing exists yet
It converts the schemas, maps and pipelines already in your BizTalk estate, so they are translated rather than retyped by hand.
Reach for it when: you are moving an estate
The AI Pipeline Builder is part of the AI Accelerator, and the Accelerator is included in every edition of iQBus. There is one limit worth knowing up front.
No add-on SKU, no separate licence, no per-seat AI charge. It is part of the platform you already have.
The Starter edition includes 100 prompts. Stated plainly here so it is not a surprise three weeks into an evaluation.
Starter is licence-free on the Azure Marketplace — installed, provisioned and registered in no more than thirty minutes.
The honest test is not whether the output compiles — it is whether the draft matches what you would have written. Pick a flow you know cold, describe it, and compare.
Install free from Azure Marketplace Read the AI Accelerator docs