Applications
An Application is the top-level container in Art2link ESB, it owns its artifacts and is closely modelled on a BizTalk Application, with one deliberate difference at the boundary.
An Application is the unit you build inside. Every artifact you define, every Port, Map, Schema, Variable, Constant, Authentication, Message type, Pipeline, Pipeline component, Custom function, NuGet package, and Activity Notification, belongs to exactly one Application.
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. Compiled code goes further still: an assembly in the GAC is visible to every application on the server. In Art2link ESB, none of that happens, and there is no exception for code. Every one of the twelve artifact kinds, including pipeline components, custom functions, and NuGet package registrations, belongs to exactly one Application. There is no shared-artifact model and no platform-wide assembly cache. 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.
An Application is created and edited in a single dialog titled Application. It holds four fields and a Save button, and that is the whole surface, everything else about the Application is reached from its menu once it exists.
| Field | What it is |
|---|---|
| Name (required) | The human-readable label, shown in the navigator and breadcrumbs. Sits on the same row as Namespace. See Name and Namespace. |
| Namespace (required) | The code-style handle used wherever the Application’s resources are addressed by identifier. Sits beside Name on the same row. See Name and Namespace. |
| Tracking | A dropdown carrying the Application’s tracking level, Only on Error, Enabled, or Enabled + Body. This is where the level is set, and it governs every port the Application owns. See Tracking levels. |
| Description | A multi-line free-text note, limited to 100 characters, with a live counter beside the field. It is a label for humans, nothing references it. |
Tracking being a field on this dialog is the practical answer to “where do I set the tracking level?”: on the Application, not on the port. A port editor has no tracking field at all, see Ports.
An Application has two identifiers. The Name is the human-readable label shown in the navigator and breadcrumbs, chosen for readability. The Namespace is a code-style handle, similar in spirit to a C# namespace, used wherever the Application's resources are addressed by identifier. Both must be code-safe, no dots and no special characters, because object names surface in expressions and editor intellisense where a dot is the path separator in tokens like {{Promoted.MessageType.Name}}. The rule applies to every named object in the platform, not just Applications (see Expressions & bindings).
The Namespace is usually derived from the Name, but the two are independent fields: renaming the Application does not change its Namespace, which stays the stable handle.
Every artifact you define belongs to one Application. The Application’s menu surfaces these twelve kinds of artifact, and the Application also owns the private bus the ports publish to and subscribe from:
| Artifact | Role |
|---|---|
| Activity Notifications | Per-application notification rules that fire on integration activity. Created and managed inside the Application. |
| Authentications | Connection details and credentials referenced by the Application’s ports. One Authentication type per Adapter type, encrypted at rest. |
| Constants | Application-scoped, dynamically-typed values defined once per deployment, for the endpoints, paths, identifiers, and toggles that differ between deployments. Referenced as {{Constant.Name}}. |
| Message types | The message classifications the Application’s ports route on, plus their Promotions. |
| Ports | The receive, send, loopback, and null ports that move messages in, out, around, and away. |
| Maps | The transformations attached to ports, XSLT plus optional custom functions. |
| Variables | Application-scoped, dynamically-typed slots. Ports and pipeline components write them; maps and custom functions can read them. |
| Pipelines | Named, ordered lists of pipeline components, attached to ports at receive or send time. |
| Schemas | The XSD or JSON Schema definitions associated with the Application’s message types. |
| Pipeline components | The C# classes the Application’s pipelines reference, compiled on save. Editing one propagates to every pipeline in the Application that uses it. |
| Custom functions | Named C# functions callable from the Application’s maps, expressions, and component property values. |
| NuGet packages | The third-party .NET libraries the Application’s pipeline components and custom functions resolve their using statements against. Registered per Application, so two Applications can hold different versions of the same package. |
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.
Application-scoped, but not an artifact: Tracking. The Tracking level is configured on the Application, in the Tracking dropdown on the Application dialog, one value of Only on Error, Enabled, or Enabled + Body that governs what every port the Application owns records. It is a setting on the container, not a thirteenth kind of artifact, and it is not configured on the individual port, a port editor has no tracking field. Plan around the consequence: inside one Application you cannot record one flow at full bodies and another at errors-only, so flows with genuinely different tracking needs belong in separate Applications.
The platform carries a Selected Application state. When you pick an Application from the navigator, every artifact screen, Activity Notifications, Authentications, Constants, Message types, Ports, Maps, Variables, Pipelines, Schemas, Pipeline components, Custom functions, NuGet packages, implicitly uses that Application as the working context. The behavior is the same on every artifact list, with no per-artifact variation.
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.
Today the boundary is absolute, but it is a deliberate default rather than a permanent one.
Deleting an Application removes the whole container: every one of the twelve kinds of artifact it owns, its private bus, and all of its tracking data. There is no partial form of the operation, the Application is the unit of deletion just as it is the unit of ownership.
Only an Application Owner can delete an Application. An Application Contributor can edit every artifact inside it and take snapshots of it, but cannot delete it. See Identity & access for the full role matrix.
1. Click Delete on the Application's row.
2. A confirmation dialog opens. Confirming is not a single click: the dialog requires you to type the Application's name before the delete is allowed to proceed.
3. Type the name exactly as it appears. The dialog carries a copy-to-clipboard control for the name, so you can copy it there and paste it into the field rather than retyping it.
4. Confirm. The Application, every artifact it owns, its private bus, and all of its tracking data are removed.
The tracking data goes with it and does not come back. A snapshot will not restore it, because a snapshot has never contained tracking history: it captures how the Application was wired, not what flowed through it. Take a snapshot before deleting and you can rebuild the configuration; the tracked runs, their statuses, and their payloads are gone. Application deletion is therefore the second thing that ends a tracked run’s life, alongside the retention window.
Deleting an Application is an audited configuration event. The actor, the timestamp, and the action land in the append-only, hash-chained audit stream, which is not part of the Application and is not removed with it.
That is the whole shape
One Application owns its twelve kinds of artifact and its private bus, its Tracking level decides what every port inside it records, the platform tracks a Selected Application to keep your lists and Create forms scoped to whichever one you are working in, and deleting the Application takes all of it, tracking data included.