Skip to content
Art2link ESB v2.02 LTS HomeDocumentationBlogContact
Core concepts/Applications

Applications

An Application is the top-level container in Art2link ESB — it owns its artifacts, sees only its own messages, and is closely modelled on a BizTalk Application with one deliberate difference: nothing crosses Application boundaries.

An Application is the unit you build inside. Every artifact you define — every Port, Map, Schema, Variable, Authentication, Message type, Pipeline, and Activity Notification — belongs to exactly one Application, and the runtime treats each Application as a self-contained world.

The shape will be familiar if you have worked with BizTalk Server: an Application here plays roughly the same role its BizTalk namesake does, as the top-level grouping that holds the artifacts of an integration. The difference is what crosses the boundary, and the answer in Art2link ESB is “nothing” — see below.

Design choice
Almost a BizTalk Application — with one boundary that doesn’t leak

A BizTalk Application groups schemas, maps, orchestrations, ports, and pipelines so they can be deployed and managed as one unit. An Art2link ESB Application groups its own equivalent set of artifacts for the same reason. Where the two diverge is at the boundary itself.

In BizTalk, artifacts in one Application are addressable from another — a schema can be referenced across applications, a message published by one application can be subscribed to by ports in another, and the message box is shared. In Art2link ESB, none of that happens. Two Applications running side by side do not see each other’s artifacts and do not see each other’s live messages or transactions. The bus a receive port publishes to is the bus its own Application’s send, loopback, and null ports subscribe to — no other Application sees it.

BIZTALK Shared MessageBox Application ASchemas, Maps,Ports, Orchestrations Application BSchemas, Maps,Ports, Orchestrations cross-app refs OK MessageBox — shared Every App publishes here; every App’s ports can subscribe. One bus, many tenants. ART2LINK ESB Private bus per Application Application Aprivate bus Application Bprivate bus no cross-app refs WHAT EACH APP HOLDS Auth · PipelinesMaps · MsgTypesSchemas · Variables Auth · PipelinesMaps · MsgTypesSchemas · Variables If both Apps need it, you define it in each. Names & namespaces never collide across Apps.
Why this matters in practice. If two Applications need the same schema, the same Authentication, or the same Pipeline, you define it in each. Names do not collide across Applications because the namespaces never meet; an Orders message type in one Application has nothing to do with an Orders message type in another.
Reference
Name and Namespace

An Application has two identifiers. The Name is the human-readable label you see in the navigator and the breadcrumb — free-form text, chosen for readability. The Namespace is an identifier-style handle, similar in spirit to a C# namespace: it follows code-friendly naming rules (no spaces, no special characters) and is what the platform uses when an Application's resources need to be addressed from a context that requires a code-safe identifier.

The two are usually closely related — the Namespace is typically derived from the Name — but they are independent fields. Renaming the Application does not retroactively change its Namespace; the Namespace is the stable handle, the Name is the label.

FieldPurpose
NameThe human-readable label. Free-form, displayed in the navigator, breadcrumbs, and lists. Can be edited to be clearer.
NamespaceThe code-style identifier. No spaces, no special characters. Used as the addressable handle for the Application's resources from places where a code-safe identifier is required.
Where you will see the Namespace. The Namespace appears in places that surface multiple Applications side by side — the Snapshots list is the visible example today — so each row stays self-describing without ambiguity. Other surfaces will use it as the platform grows the cross-Application story.
Reference
What lives inside an Application

Every artifact you define belongs to one Application. The Application’s menu surfaces these eight kinds of artifact, and the Application also owns the private bus the ports publish to and subscribe from:

SCOPE Application — one container, eight artifact kinds, one private bus ARTIFACTS Activity NotificationsPer-app alert rules AuthenticationsCredentials, encrypted Message typesClassifications & promotions PortsReceive / Send / Loopback / Null MapsXSLT + custom functions VariablesApp-scoped, dynamic slots PipelinesOrdered component chains SchemasXSD or JSON Schema Private bus — the only thing receive, send, loopback, and null ports publish to and subscribe from BOUNDARY No artifact, no message, no transaction crosses this line into another Application.
ArtifactRole
Activity NotificationsPer-application notification rules that fire on integration activity. Created and managed inside the Application.
AuthenticationsConnection details and credentials referenced by the Application’s ports. One Authentication type per Adapter type, encrypted at rest.
Message typesThe message classifications the Application’s ports route on, plus their Promotions.
PortsThe receive, send, loopback, and null ports that move messages in, out, around, and away.
MapsThe transformations attached to ports — XSLT plus optional custom functions.
VariablesApplication-scoped, dynamically-typed slots that pipelines, ports, and maps can read and write.
PipelinesNamed, ordered lists of pipeline components, attached to ports at receive or send time.
SchemasThe XSD or JSON Schema definitions associated with the Application’s message types.

Each row above (except Activity Notifications, which is documented in-app today) has its own article in this documentation set — the Application is what holds them together.

UI behavior
Selected Application

The platform carries a Selected Application state. When you pick an Application from the navigator, every artifact screen — Activity Notifications, Authentications, Message types, Ports, Maps, Variables, Pipelines, Schemas — implicitly uses that Application as the working context. The behavior is the same on every artifact list, with no per-artifact variation.

SELECTED — none — Schemas list APPLICATION NAME FORMAT OrdersCustomerOrderXSD OrdersLineItemXSD BillingInvoiceJSON BillingCreditNoteJSON LogisticsShipmentXSD LogisticsManifestXSD List spans every App. Application column on; Create shows a picker. SELECTED Orders Schemas list NAME FORMAT CustomerOrderXSD LineItemXSD Click Create → new schema form opens with Application = Orders preselected. No picker. List filtered to one App. Application column off — redundant.

Two consequences follow.

Creation forms. When a Selected Application is set and you click Create on an artifact list, the new-artifact form opens with that Application preemptively chosen — you fill in the rest of the fields and save. When no Application is selected, the form exposes an Application picker and you choose one before saving. The artifact ends up owned by whichever Application you picked, exactly the same either way.

Grid columns. When a Selected Application is set, the artifact list does not show an Application column — every row in the list belongs to the same Application, so the column would be redundant. When no Application is selected, the list spans every Application you have access to, and the Application column appears so each row stays self-describing.

If you cannot find an artifact. Check whether you have a Selected Application. With one selected, every list is filtered to it — an artifact owned by another Application will not show up until you clear the selection or switch to the right one.
Runtime
Isolation between Applications

Two Applications running on the same instance do not share anything. None of the artifacts above is visible from another Application — no schema, no map, no message type, no variable, no authentication, no pipeline, no port, no notification rule. Live messages and in-flight transactions are equally isolated: a message published to the bus by a receive port in Application A is invisible to every port in Application B, and vice versa.

This is the deliberate default. The reason it is worth calling out is that BizTalk operators arrive expecting cross-application addressability and shared message-box semantics; Art2link ESB does not provide either today.

⏳
Coming soon: explicit cross-application access. A near-term release will let an Application grant explicit, permissioned access to specific artifacts and resources for users and other Applications. Until then, treat the boundary as absolute.

That is the whole shape

One Application owns its eight kinds of artifact and its bus. Nothing crosses the boundary in either direction today — and when cross-application access ships, it will be explicit, scoped, and opt-in.