WorkPoint Event Bus: Partner Day Demonstration

For our solution, the WorkPoint setup is relatively simple.  First, a Projects Business Module is configured using WorkPoint’s One Site architecture ​[4]​.  

Readers familiar with WorkPoint will recognize that every Project Entity is represented as a List Item in the Projects Business Module List. Our Projects module includes metadata fields to specify the Project Title, AD users for the Project Manager (PM) and Project Sponsor (PS). WorkPoint’s Numerator Service was used to automatically generate a unique Project ID for each project and Dynamic Security Rules used to automatically grant the PM and PS visibility of and access to the Entity and its associated site. 

As projects are created, WorkPoint assigns an independent Site Collection (the “Project Site”), with site contents based on a Master Site template - including a simple Task list with standard task columns (Title, Due Date, Assigned To etc.) 

We now have an operational Project system! As PMO users create Projects (Entities), assign Project Manager and Project Sponsor. WorkPoint will provision a Project Site (site collection), and the Project Manager can use the Projects Task list to assign and track Tasks across their project team. 

To make the Project and Task data available for reporting, and to keep the information automatically up to date, we enable the WorkPoint Event Bus feature. This involves: 

• In the Azure Portal, creating an Azure Event Grid Service and adding Azure Event Grid Topic for WorkPoint Events. 
• In the WorkPoint Admin Portal; access the Event Bus settings panel and specify the Endpoint URL for your Event Grid Topic (Figure 3.A) and provide an Access Key (generated in the Azure Portal - B)  
• Configure which Project Entity and Project Task events (New/Updated/Deleted) are broadcast to the Event Grid. (Figure 3.C)

Figure 3: Event Mapping 

Now, any time a Project or Project Task is created, updated, assigned, or deleted – an event is instantly published to the Event Grid. Behind the scenes, each event consists of a JSON payload of data (like the example below) describing the Project event and including all metadata. 

Figure 4: Event Data. Each event is sent to the Event Grid as JSON data. Note the “EventType” property matches the value defined in WorkPoint settings (Figure 3.C) 

Once the event is passed to the Azure Event Grid, there is no further processing done by WorkPoint services and code. What happens next is all handled in Azure. 

It’s important to note that every event is atomic, it defines the state of a Project or Task at a given point in time and so subsequent actions on the same source object will supersede all prior event data. To keep the source WorkPoint Solution and target DataVerse in sync, we need reliable and efficient processing of events.  

This is where Azure’s Event Grid excels –seamlessly handling event ingestion, authenticating origin, validating event structure then publishing the event to all interested subscribers.  Importantly, it does this at almost infinite scale, ensuring events are received in the correct order and providing advanced resilience and fault handling tools. 

With WorkPoint data now instantly flowing into the Azure Event Grid, we need simply implement an Event Subscriber to receive these events and an Event Handler to process or storing event data. All our remaining configuration is done in Azure.

In the Azure Event Grid Topic settings, two distinct Event Subscriptions are added: Project Entity events and Project Task events are routed to distinct Event Handlers using a simple “startswith” filter on Event Grid subscriber settings. 

Event handlers can be any application that can be triggered by a webhook (HTTP:Post) event,  to maintain a low/no-code approach, in our solution we implemented these as no-code Azure Logic Apps ​[5]​.  

Figure 5 below shows our two Event Subscriptions that use a simple “Prefix” filter on the Event Type field (Figure 5.A) are used to distinguish ProjectEntity from ProjectTask events. Each subscriber uses a Webhook to invoke an Azure Logic App with a JSON payload of WorkPoint events. 

Figure 5: Event Grid Subscribers – Logic App Workflow 

In the Tenant’s DataVerse, Projects and ProjectTasks tables were created in the Azure Tenant’s DataVerse – using column structures mirroring the metadata fields in the WorkPoint Projects Business Module and Tasks lists (see Figure 6). 

Figure 6: WorkPoint to DataVerse - Projects Data 

As shown in the Logic App Flow (Figure 5), each Logic App Event Handler simply parses the event payload, identifies the Event Type (create, update, delete), then sequences the appropriate DataVerse actions to add, update or delete rows in the DataVerse tables.  

Now, in WorkPoint, as PMO Users interact with Project Entities and Project Users interact with Project Tasks, the WorkPoint Event Bus sends each change through the Azure Event Grid, the subscriber logic apps parse and handle the data and the DataVerse tables are kept in-sync.  

To allow Managers to see where and how their employees are being assigned tasks in any project, we needed some Organizational Data for Project Users (specifically; Department and Manager.). 

We collected AD information in a ProjectUsers DataVerse table using a simple Power Automate cloud-flow triggered by the O365 Event “When a Group Member is Added or Removed”.  

When a user is added or removed from the same AD group we use for our Security Rules and User Lookups (Project Manager, Sponsor, Assigned To etc.), the flow simply gathers the Manager and Department information from the AD Profile and populates the ProjectUsers table. 

With Projects, Project Tasks and User data flowing into the DataVerse from the Event Handlers, we have a dataset that can represent all projects in the organization. Figure 7 below shows the full schema.  

Figure 7: Event Handling to Persistence 

With this schema, Projects and Project Tasks can be associated using the Entity and Business Module ID values that WorkPoint provides (Figure 7.A). Users in the Project Manager, Sponsor, Assistant or in Task AssignedTo fields, can be enriched with the Organization Profile information provided by the Project Users flow (B & C) using a Lookup on the UserPrincipalName (upn). 

DataVerse now contains all the information we need to drive the Project Dashboard  

The information in our Projects, ProjectTasks and ProjectUsers tables allows the report to display all Project information and filter by organizational data such the Department (of Project Sponsor). 

Now PMO and Project Sponsors can easily view the up-to-date status of their initiatives in one view independent of the underlying SharePoint site structure. Further drill-down reports can use the Project Task level detail to understand where and how Tasks are assigned across the organization – providing Managers with visibility of tasks assigned to their direct reports. 

Job done! 

Figure 8: WorkPoint Event Grid Demo - PowerBI Dashboard. The PowerBI report can provide an overview and drill-down detail for Project and Task level detail supporting filtering by Organizational data (A), drill-down to Project level detail (B) and includes role/department detail for Task-level data (C & D).