Before Art2link, we developed integrations the way everyone did: open Visual Studio, write, compile, deploy, restart, and hope that what worked on the development machine still worked once it landed. The work you did at ten in the morning met reality at ten at night, and when it failed, it failed in production, after the downtime window had already been spent. Every item below is a direct answer to something on that grudge list.

You never open Visual Studio, or any IDE, to build on Art2link ESB. Ports, pipelines, maps, and every line of code the platform accepts, XSLT 3.0 maps, C# pipeline components, C# custom functions, are authored and saved in the portal. The portal is the development environment.

The platform is 100% configurable, and that is a strict rule, not a tendency. Nothing you write requires a build step. Even C# pipeline components and custom functions, including ones that pull in NuGet packages, are saved and run. There is no solution file, no build pipeline, no artifact to produce. If it needs compiling before the platform can use it, it does not belong in the platform.

What you save is what runs, the moment you save it. There is no separate deployment step where weeks of work meet the runtime for the first time and lose. The disconnect between writing code and discovering whether it actually works, the one that used to surface as a deployment-night incompatibility, does not exist, because there is nothing between you and the running platform.

Saving a change never restarts a service, and never takes the platform down. Changes propagate to the running system live. A restart is downtime by another name, and downtime to apply a change you already finished writing is a tax we refused to pay. On Art2link ESB it is simply not part of the model: there is nothing to restart.

BizTalk was tightly coupled by design, and eventually grew the ESB Toolkit and its itineraries to loosen up. Art2link ESB starts loose and lets you tighten where tightness earns its keep. Two artifacts carry most of that choice:

Schemas are optional. In BizTalk a schema is mandatory and defines the message type. Here a message type is just a name, and a schema exists for one purpose only: validation, where you choose to apply it.

Maps come in two modes. A Typed map is keyed on the source message type and behaves the way BizTalk trained you to expect: the types must match. A Universal map runs regardless of the source type, maps whatever matches, and ignores whatever does not, the same spirit as the itineraries, built in rather than bolted on.