Business Events & Azure Integration

Every integration pattern we have covered so far involves someone asking F&O for data — polling, querying, exporting. Business events flip the model: F&O tells external systems when something happens. This is event-driven architecture, and it is the modern way to build loosely coupled, reactive integrations.

The Business Events Framework

How it works

1. Something happens in F&O — a business process reaches a milestone
2. The application code raises a business event
3. The framework checks if the event is activated for the current legal entity
4. If activated, the event payload (JSON) is sent to the configured endpoint
5. The external system receives and processes the event

🔗 Marcus’s integration evolution: “When I started in this space, integrations meant nightly batch files and prayer. Business events changed everything. Now when Anita’s finance team confirms a sales order, her warehouse system knows within seconds — not hours. And if the warehouse system is down? The message sits in Service Bus until it comes back online. That is reliability.”

Business Events Catalog

F&O ships with dozens of standard business events covering major business processes:

Category	Example Events
Sales	Sales order confirmed, Sales order invoiced, Sales order packed
Purchasing	Purchase order approved, Purchase order confirmed
Finance	Free text invoice posted, Payment journal posted
Inventory	Transfer order shipped, Counting journal posted
Workflow	Work item created, Work item completed, Workflow approved
Batch	Batch job completed, Batch job failed
Alerts	Alert rule triggered (user-configured)

You browse the full catalog in System administration → Setup → Business events → Business events catalog.

Activating Business Events

Business events must be activated before they fire. Activation is per-legal-entity:

1. Go to Business events catalog
2. Find your event (e.g., “Sales order confirmed”)
3. Click Activate
4. Select the legal entity (or all)
5. Select the endpoint (where to send it)

🔗 Marcus’s governance note: “Never activate all events to all endpoints — you will drown your downstream systems. Activate only the events each system needs. Anita’s warehouse needs ‘Sales order confirmed’ and ‘Transfer order shipped’. That is it. Her finance reporting system needs ‘Invoice posted’. Different systems, different events, different endpoints.”

Question

What is a business event in F&O?

Click or press Enter to reveal answer

Answer

A business event is a notification raised by F&O when a business process reaches a milestone (e.g., order confirmed, invoice posted). It carries a JSON payload describing what happened and is delivered to configured endpoints (Service Bus, Event Grid, HTTPS, Power Automate). Events must be activated per legal entity.

Click to flip back

Creating Custom Business Events

When standard events don’t cover your scenario, you build a custom business event. This involves three pieces:

1. Business event contract (payload)

Defines the data sent with the event.

[DataContractAttribute]
class CustCreditLimitExceededContract extends BusinessEventsContract
{
    CustAccount     custAccount;
    AmountMST       creditLimit;
    AmountMST       currentBalance;
    str             custName;

    public static CustCreditLimitExceededContract
        newFromCustTable(CustTable _custTable, AmountMST _balance)
    {
        CustCreditLimitExceededContract contract = new CustCreditLimitExceededContract();

        contract.parmCustAccount(_custTable.AccountNum);
        contract.parmCreditLimit(_custTable.CreditMax);
        contract.parmCurrentBalance(_balance);
        contract.parmCustName(_custTable.name());

        // BusinessEventsContract requires legal entity context
        contract.parmLegalEntity(_custTable.dataAreaId);

        return contract;
    }

    [DataMemberAttribute('CustomerAccount')]
    public CustAccount parmCustAccount(CustAccount _value = custAccount)
    {
        custAccount = _value;
        return custAccount;
    }

    [DataMemberAttribute('CreditLimit')]
    public AmountMST parmCreditLimit(AmountMST _value = creditLimit)
    {
        creditLimit = _value;
        return creditLimit;
    }

    [DataMemberAttribute('CurrentBalance')]
    public AmountMST parmCurrentBalance(AmountMST _value = currentBalance)
    {
        currentBalance = _value;
        return currentBalance;
    }

    [DataMemberAttribute('CustomerName')]
    public str parmCustName(str _value = custName)
    {
        custName = _value;
        return custName;
    }
}

2. Business event class

Defines the event itself — its ID, description, and contract.

[BusinessEventsAttribute('CustCreditLimitExceeded',
    'Customer credit limit exceeded',
    'Raised when a customer balance exceeds their credit limit',
    ModuleAxapta::SalesOrder)]
class CustCreditLimitExceededEvent extends BusinessEventsBase
{
    CustTable   custTable;
    AmountMST   currentBalance;

    public static CustCreditLimitExceededEvent
        newFromCustTable(CustTable _custTable, AmountMST _balance)
    {
        CustCreditLimitExceededEvent event = new CustCreditLimitExceededEvent();
        event.custTable = _custTable;
        event.currentBalance = _balance;
        return event;
    }

    protected BusinessEventsContract buildContract()
    {
        return CustCreditLimitExceededContract::newFromCustTable(
            this.custTable, this.currentBalance);
    }
}

3. Raising the event

Call this from the business logic where the event should fire.

// In the credit check logic
if (currentBalance > custTable.CreditMax)
{
    CustCreditLimitExceededEvent businessEvent =
        CustCreditLimitExceededEvent::newFromCustTable(custTable, currentBalance);

    businessEvent.send();
}

What’s happening in the three pieces:

• The contract (CustCreditLimitExceededContract) extends BusinessEventsContract and defines the JSON payload fields
• The event class (CustCreditLimitExceededEvent) extends BusinessEventsBase, carries the BusinessEventsAttribute that registers it in the catalog, and builds the contract in buildContract()
• The send() method checks if the event is activated for the current legal entity and delivers it to configured endpoints

🏗️ Vik’s code review: “Three things I always check in custom business events: (1) Does the contract inherit from BusinessEventsContract? (2) Is parmLegalEntity set? Without it, the event won’t match any activation. (3) Is send() called inside a ttsCommit block? Events should only fire after the transaction succeeds — never on a path that might roll back.”

💡 Exam tip: BusinessEventsContract base class

The exam will test whether you know that custom business event contracts must extend BusinessEventsContract (not just DataContractAttribute). The base class provides parmLegalEntity, parmBusinessEventId, and serialization support. If your contract extends a plain class, the business events framework won’t recognise it.

Question

What three classes do you create for a custom business event?

Click or press Enter to reveal answer

Answer

1) A contract class extending BusinessEventsContract — defines the JSON payload with DataMemberAttribute fields. 2) An event class extending BusinessEventsBase with BusinessEventsAttribute — registers the event in the catalog and builds the contract. 3) Raising code that calls event.send() from the business logic at the appropriate milestone.

Click to flip back

Endpoints

Endpoints define where business events are delivered. F&O supports four endpoint types.

Azure Service Bus

The most common endpoint for enterprise integrations. Service Bus provides:

• Queues — point-to-point messaging (one consumer per message)
• Topics — publish-subscribe (multiple consumers per message)
• Dead-letter queue — failed messages are preserved for investigation
• Guaranteed delivery — messages persist until consumed

Configuration: Provide the Service Bus connection string and queue/topic name.

Azure Event Grid

For high-throughput, low-latency event routing. Event Grid excels at:

• Fan-out to many subscribers
• Filtering events at the platform level
• Serverless triggers (Azure Functions, Logic Apps)

Configuration: Provide the Event Grid topic endpoint and access key.

HTTPS Webhook

A simple POST to any HTTPS URL. The event payload is the request body.

• Simplest to set up
• No guaranteed delivery — if the endpoint is down, the event is lost (unless you add retry logic)
• Good for: Power Automate custom connectors, third-party SaaS webhooks

Microsoft Power Automate

A direct integration — business events trigger Power Automate flows without any intermediate infrastructure.

• Use the Finance and Operations connector’s When a business event occurs trigger
• No need to configure Service Bus or Event Grid
• Perfect for: approval workflows, email notifications, Teams alerts

Business Event Endpoints Compared

Endpoint	Delivery	Reliability	Best For
Azure Service Bus	Queue/Topic	Guaranteed (persist until consumed)	Enterprise middleware, high-reliability integrations
Azure Event Grid	Push (HTTP)	At-least-once with retry	High-throughput fan-out, serverless triggers
HTTPS Webhook	POST to URL	No guarantee (fire-and-forget)	Simple integrations, third-party SaaS
Power Automate	Direct trigger	Platform-managed retry	Low-code workflows, notifications, approvals

Question

What are the four business event endpoint types in F&O?

Click or press Enter to reveal answer

Answer

1) Azure Service Bus — queues/topics with guaranteed delivery. 2) Azure Event Grid — high-throughput event routing with filtering. 3) HTTPS Webhook — simple POST to any URL (no delivery guarantee). 4) Power Automate — direct trigger for low-code flows.

Click to flip back

Azure Key Vault Integration

Business event endpoints need connection strings, access keys, and secrets. Hardcoding these is a security risk. Azure Key Vault provides secure, centralised secret management.

How F&O uses Key Vault

1. Store secrets in Azure Key Vault (connection strings, API keys, certificates)
2. Register the Key Vault in F&O (System administration → Setup → Azure Key Vault parameters)
3. Reference secrets by name when configuring endpoints, certificates, or external connections
4. F&O retrieves the secret at runtime — the value never appears in F&O configuration

Configuration steps

1. Create a Key Vault in Azure
2. Register an app in Entra ID for F&O to authenticate to Key Vault
3. Grant the app Get and List permissions on Key Vault secrets
4. In F&O: System administration → Setup → Key Vault parameters
   • Enter the Key Vault URL (e.g., https://nexbridge-vault.vault.azure.net/)
   • Enter the app registration’s client ID and secret
5. Add secrets — map friendly names to Key Vault secret names
6. Reference the friendly names in endpoint configurations

🔗 Marcus’s security stance: “Rafiq asked why we can’t just paste the Service Bus connection string directly into the endpoint config. Three reasons: (1) the connection string is visible to anyone who can view the endpoint setup, (2) when you rotate the key, you have to update every endpoint manually, and (3) it violates every security audit checklist I have ever seen. Key Vault or nothing.”

💡 Exam tip: Key Vault vs endpoint configuration

The exam tests whether you know that secrets in F&O endpoint configurations should come from Azure Key Vault — not pasted directly. If a question asks “how to securely store the Service Bus connection string for a business event endpoint”, the answer is Azure Key Vault. Also remember: F&O needs an Entra ID app registration with Key Vault access permissions — it cannot access Key Vault anonymously.

Question

Why should F&O integration endpoints use Azure Key Vault?

Click or press Enter to reveal answer

Answer

Azure Key Vault provides secure, centralised secret management. Benefits: (1) Secrets aren't visible in F&O configuration screens. (2) Key rotation updates one place — Key Vault — not every endpoint. (3) Access is audited and controlled via Entra ID permissions. F&O retrieves secrets at runtime via an authenticated app registration.

Click to flip back

Event-Driven Architecture Patterns

Pattern 1: Event → Service Bus → Multiple Consumers

F&O: Invoice Posted
     │
     └─→ Service Bus Topic
              │
              ├─→ Subscription 1 → Reporting System (update dashboard)
              ├─→ Subscription 2 → Email Service (send receipt)
              └─→ Subscription 3 → Archive System (store document)

One event, multiple subscribers, each processing independently. If one fails, the others are unaffected.

Pattern 2: Event → Power Automate → Action

F&O: Purchase Order Approved
     │
     └─→ Power Automate
              │
              ├─→ Send Teams notification to buyer
              ├─→ Create task in Planner
              └─→ Update SharePoint tracking list

Low-code workflow triggered directly by a business event.

Pattern 3: Event → Event Grid → Azure Functions

F&O: Inventory Below Threshold
     │
     └─→ Event Grid
              │
              └─→ Azure Function
                       │
                       ├─→ Call supplier API for reorder
                       └─→ Log to Application Insights

Serverless compute reacting to business events.

🔗 Marcus’s architecture principle: “The beauty of event-driven is decoupling. F&O doesn’t know or care what happens after it fires the event. The warehouse system, the email service, the reporting dashboard — they all subscribe independently. If we add a new consumer next month, F&O doesn’t change at all.”

ℹ️ Business events vs alerts vs database events

F&O has three event-like features — don’t confuse them:

• Business events: Developer-defined events raised at business process milestones. External-facing. JSON payloads delivered to endpoints.
• Alerts: User-configured notifications for record changes (e.g., “notify me when a customer is created”). Internal to F&O — trigger email or Action Centre notifications, or business events if configured.
• Database events: Low-level change tracking for internal sync (dual-write, change tracking). Not directly consumable as integration events.

The exam may present scenarios where each is appropriate. Business events = external integration. Alerts = internal user notification. Database events = sync infrastructure.

Exam Practice

Knowledge Check

When a sales order is confirmed in F&O, a warehouse system, a reporting dashboard, and an email service all need to be notified. Which endpoint type should Marcus configure?

AHTTPS webhook to each system individuallyBAzure Service Bus topic with three subscriptionsCAzure Event Grid with three separate eventsDPower Automate with three parallel branches

Check Answer

Knowledge Check

Vik creates a custom business event contract but forgets to extend BusinessEventsContract. What happens?

AThe event fires but the payload is emptyBThe event appears in the catalog but crashes when activatedCThe event does not appear in the business events catalogDThe event fires normally — the base class is optional

Check Answer

Knowledge Check

Marcus needs to store the Azure Service Bus connection string for a business event endpoint. Where should it be stored?

AIn the endpoint configuration field directlyBIn a configuration file on the F&O serverCIn Azure Key Vault, referenced from F&O Key Vault parametersDIn a custom database table with encryption

Check Answer

Knowledge Check

Which of the following correctly describes the relationship between BusinessEventsBase and BusinessEventsContract?

ABusinessEventsBase contains the payload; BusinessEventsContract handles deliveryBBusinessEventsBase defines the event and builds the contract; BusinessEventsContract defines the payloadCThey are interchangeable — either can be used as the event classDBusinessEventsContract extends BusinessEventsBase

Check Answer

Question

Where in F&O do you activate business events?

Click or press Enter to reveal answer

Answer

System administration → Setup → Business events → Business events catalog. Select the event, click Activate, choose the legal entity (or all), and select the endpoint. Events only fire when activated for the specific legal entity where the business process runs.

Click to flip back

Question

What are the three event-like features in F&O and when is each used?

Click or press Enter to reveal answer

Answer

1) Business events — developer-defined, external-facing, JSON payloads to endpoints (Service Bus, Event Grid, HTTPS, Power Automate). 2) Alerts — user-configured, internal notifications for record changes (email, Action Centre). 3) Database events — low-level change tracking for sync infrastructure (dual-write). Use business events for external integration, alerts for internal user notifications.

Click to flip back

---

Domain 6 complete! 🎉 You have covered the full integration landscape — from choosing the right pattern and API, through DMF and custom services, to dual-write, virtual entities, and event-driven architecture.

Next up: Domain 7 — Security: Roles, Duties, Privileges & XDS — implement security architecture and optimise performance.