Request and Change¶
Almost every change to the Integration Platform is a standard change: you describe what you want, the platform team or you (through a pull request) change the configuration in code, it is reviewed and deployed. You do not create queues, topics or integration resources by hand in the portal, because the next deployment would undo it.
Which intake you use depends on your platform (Operating models). Support hours,
response and resolution targets and the contact channel (<support channel>) are in your agreement, not here.
How changes are made¶
| Form | How it works |
|---|---|
| Request | You describe the change in a ticket or work item. The platform team prepares the pull request. |
| Pull request | You change the configuration yourself (for example queues.json, or the module call of your workload repository) and open a pull request. The platform team or the integration platform engineers review and deploy it. The platform accepts pull requests from builders, also to improve its own processes. |
All interaction with the platform is by Git and pull request, which gives version control and traceability. The steps are:
- The change is a pull request, prepared by you or on request.
- A reviewer checks it. For Service Bus entities see the checklist.
- It is deployed through the pipeline. Deployments of your own workload resources are started by hand (Deploy integration resources).
- You are informed and the ticket is closed.
Standard changes¶
| Change | Class | What you provide | Where it is configured |
|---|---|---|---|
| Turn a shared service on or off (Service Bus, Event Hubs, API Management, container registry) | Optimisation | The service, the environments and who will use it | Spoke file, extension enabled (Spoke extensions) |
| Connect an integration workload spoke to the shared services | Enablement | The spoke and the extensions you need | Spoke file (Spoke JSON) |
| Add, change or remove a Service Bus queue or topic | Enablement | The entity, its properties, producer and consumer workloads | queues.json or topics.json (Service Bus) |
| Add or remove people or groups in a Service Bus sender or receiver group | Enablement | The group, the members | Entra ID. You can do this yourself as owner of the group. |
| Add, change or remove an API in API Management and the Application Gateway | Enablement | The API definition, backend, products, subscriptions | APIOps repository, and gateway definitions (Shared services) |
| Request a new integration pattern or module (Logic App, Function App, Container App, Data Factory) | Enablement | The module, spoke, environment and settings | Module call in your workload repository (Modules) |
| Add integration platform engineers | Enablement | The persons and the role | Platform access, per your agreement |
Changes outside this list, such as a new module option or a new shared service, are changes of the platform, not standard changes. They are assessed first (Service types).
What to put in a request¶
| Request | Include |
|---|---|
| Shared service or extension | The spoke, the service (apim, acr, servicebus, eventhub), the environments, the people who will use it |
| Queue or topic | Workload, entity names, queue or topic and, for a topic, the subscribing workloads. Properties that differ from the defaults (delivery count, TTL, sessions, duplicate detection, size). Whether a filter rule is needed. |
| Module | Which module, the spoke and environment, subnet names to use, sizes, the identity for pulling images (Container App), authentication settings (Logic App) |
| API | Name, path, backend URL, OpenAPI file, products, subscriptions. No keys in the request: reference Key Vault secrets. |
| Firewall rule | Source, destination (FQDN or IP group), port. Needed for every connection that leaves your spoke (Firewall rules and IP groups). |
Who does what¶
| Platform team | Workload team | |
|---|---|---|
| Deploy and operate shared services and the platform pipelines | Yes | |
| Review and deploy entity and module changes | Yes | Prepare the pull request |
| Manage group membership of your entities | Yes | |
| Decide on the properties of your queues, APIs and resources | Yes | |
| Firewall rules | Validate and deploy | Request |
The generic split is in Responsibilities and Operating model.