Artifact translation
Everything you built in BizTalk goes somewhere in Art2link ESB, but not always to the thing with the same name. This is the artifact-by-artifact map, with the traps called out.
| BizTalk | Art2link ESB | What changes |
|---|---|---|
| Application | Application | Same role: the unit that owns an integration’s artifacts. Names follow code-safe rules (no dots or spaces). |
| MessageBox | The bus | The platform’s own purpose-built message exchange at the center; the same publish-subscribe semantics you already rely on. |
| Receive port + receive location | Receive port | One artifact instead of two; the adapter and its Authentication are configuration on the port. Running / stopped, immediate effect. |
| Send port / send port group | Send port + subscriptions | Subscription expressions replace filter grids; retry and backoff live on the port. |
| Pipeline | Pipeline | Same stage idea; components are configured per stage in the portal. Changing a component’s code, not just its configuration, takes effect immediately: no deployment and no service restart to refresh a cache. |
| Custom pipeline component (.NET, GAC) | Pipeline component (C#) | The same idea as in BizTalk, saved in the platform rather than the GAC. |
| Schema (XSD) | Message type + optional schema | The schema concept splits in two: the message type is just an identifier that classifies a message, and a schema is now optional, used for validation. JSON schemas are supported alongside XSD. |
| Promoted property | Promotion on the message type | A promotion lifts a value out of the payload for easy, readable access in routing, referenced as {{Promoted.MessageType.Name}}. Routing does not require it: an XPath expression over the body routes just as well. Promote what you route on or bind into an adapter parameter. |
| Distinguished field | Folded into Promotion | BizTalk split promoted properties (for routing) from distinguished fields (for orchestration access). With no orchestrations, that split is pointless, so the two collapse into one idea, the promotion. Anything you do not promote is still readable in subscriptions and Variable assignments with {{Message.Body}}.XPath. |
| Map (Saxon HE + functoids) | Map (Saxon HE, XSLT 3.0) | See below. |
| Bindings file | Snapshot (+ Authentications, Constants) | A snapshot is a portable capture of the Application’s configuration, optionally including its Authentications and Constants. Whatever sensitive material is included is encrypted in the snapshot; environment-specific values are Constants re-valued at import. |
| BAM, tracked message events | Tracking + Activity Notifications + Logs | Built in, no activity models or deployment, unlike BAM, which you had to implement. Per-port tracking levels; alert emails per Application; audit and compliance streams in Logs. |
| Business Rules Engine | No direct counterpart | See below, expressions and custom functions cover the common uses. |
| ESB Toolkit (itineraries) | Native behaviour | The bus is the ESB; routing slips become subscriptions over canonical types. |
| Orchestration | Composition | Deliberately absent, its own article. |
In BizTalk, the XSD is the type: deploy the schema or nothing moves. In Art2link ESB a message type is a name a receive port stamps on a message; classification happens in the pipeline or via the port’s Publish Message Type Fallback, and no schema is required for a message to flow. Schemas still exist, but as optional validation you attach deliberately where bad payloads must not pass, at the edge typically. And schemas are no longer XSD-only: a JSON payload can be validated against a JSON Schema, not just XML against an XSD.
Practically, this inverts a migration chore into a relief: you do not port your XSD library first. You name your types, promote the handful of values you route on, and bring validation in only where it pays rent. Your canonical XSDs remain useful exactly there.
Maps. Your XSLT skills carry straight over; what changes is how you author a map. After more than twenty years of building maps on BizTalk’s visual grid, we concluded that writing the transform directly in XSLT is easier to understand, more efficient, and easier to manage and review than wiring functoids. So an Art2link map is XSLT 3.0: what a functoid did, an XPath 3.1 expression or a custom function called via art:invoke does in readable text you can diff. We use the same Saxon HE engine BizTalk does, but we do not support functoids. Because the custom functions a map calls compile and take effect on save, with no deploy and no service restart, maps inherit that immediacy, and the map entity itself behaves the same way. The direction of travel is deliberate: the roadmap is for the AI Accelerator to draft these maps, so that increasingly they are written by AI rather than by hand.
Pipeline components and helper code. Custom .NET components stop being assemblies you build and deploy into the GAC and become C# classes saved in the platform, with shared logic in custom functions and external libraries via NuGet packages. Changing a component is like changing a configuration value: it compiles and takes effect on save, with no rebuild, no deployment, and no service restart. The discipline that carries over: components are written data-driven, so everything that varies per message is read from the message.
Business Rules Engine. There is no rules engine, and pretending otherwise would cost you a failed test later. The honest mapping: vocabulary-and-policy routing rules become subscription expressions over promoted values; computed decisions become custom functions; rules a business user was meant to edit at runtime have no counterpart today and belong on your triage list.
| BizTalk adapter | Art2link adapter |
|---|---|
| FILE | File Share (or Azure Blob for cloud storage) |
| FTP / SFTP | SFTP |
| SQL / WCF-SQL | SQL |
| HTTP / WCF (HTTP services) | API, Listener for inbound, Caller for outbound |
| MQSeries | MQ Series |
| SB-Messaging | Service Bus |
| POP3 / SMTP | O365 Mail |
| Scheduled task adapter (community) | Scheduler, first-class, drives every polling flow |
| SAP / Salesforce / IBM & LOB adapters | SAP, Salesforce, CloudSuite, Grow and Enterprise editions only |
Mapping is protocol-level; capabilities and direction specifics live in each adapter article. Two habits to unlearn: polling sources are built as Scheduler-driven flows rather than per-adapter polling settings, and SOAP-era WCF bindings have no counterpart, inbound and outbound HTTP is REST-shaped through the API adapter, which is where most WCF endpoints were heading anyway.