Embedded DMO

ARCHIVED

This document was originally specifying a form of the DMO app that could live as a microfrontend in other apps, adopting the local styling, etc. We did not implement such a thing, but we're leaving it here for archival reference.

The Problem

Application developers who need to build features to create or modify data in the party domain will find that our architecture prohibits direct creation or modification of several entities, thus requiring the user to contact the Data Management Office (DMO). This is a necessary restriction to maintain data quality, described in detail in the overview section of this documentation.

Understandably, using the DMO as a gate to creating data may result in occasional customer satisfaction issues. While it is important to understand that even though realtime SLAs are not necessary for almost every business transaction at UTA, we must develop an approach to recover CSAT should the concern arise, through:

• Predictable service level agreements (SLAs) for all DMO services
• Reduced friction in requesting DMO services

Predictable SLAs

Reduced friction through the EmbeddedDMO

What should be the mechanism with which new entities shall be requested?

The worst thing to do is to force the user who finds themselves needing an entity to leave the context of their application and go to a separate web page, or application like ServiceNow, or even a raw email to create a "ticket" to request an entity.

We can greatly reduce the friction here by allowing application developers to embed the request and response process into their applications. This is what we are calling the embedded DMO.

To the user, the process will feel like they are working in their familiar application.

POSSIBLE IMPLEMENTATION APPROACHES

One approach could be to create a a composable, decoupled frontend that can be composed into applications like a regular, local React component. There was considerable excitement about microfrontends for a while, and some frameworks such as SingleSPA popped up to address the need.

Eventually, a relatively new capability built into bundlers like Webpack and Rollup called module federation appeared.

For Vite and React, which do not use Webpack but rather esbuild, we might consider using the vite-plugin-federation plugin. If you'd like to review some demo source code of the Vite+React solution, you can find it here.

Admittedly, this is the most "out-there" part of the entire product design. After some experimentation with module federation, we would not recommend it for production use in UTA applications. It would be better to wait to see how React Server Components,which are still in experimental beta, might be used.

A Microsoft product manager has been evangelizing what she believes is a better term ("composable, decoupled frontend") and is writing about architectural patterns and tools for designing and building these frontends at microfrontend.dev.

NearForm wrote a fairly recent (as of August 2023) survey of microfrontend approaches.

Requesting to create or modify party data

The following diagram shows the sequence of events that occur when a user wants to create or modify data about a party. For simplicity we have left out the messages from the Authoritative Data API to the Authorization service.

TODO: Customize the sequence diagram

https://mermaid.js.org/syntax/sequenceDiagram.html#configuration

Responding to a DMO Decision

The mechanism by which an application can "find out" about the DMO decision is still under design, but it is likely that we will support three mechanisms:

1. A webhook that the application can register with the DMO service which will be called when a decision is made
2. A websocket connection that the application can open with the DMO service which will be used to send decisions
3. A polling mechanism where the application can periodically check the DMO service for decisions, e.g., GET /dmoRequests

TODO: Response formats

Compose the formats for two types of responses:

• Decisions
• Questions (future)

Decisions. One idea is to send back a URI that will lead to the right representation, so the app can follow the link to get the data it would need to complete the transaction, or offer to the user.

This will work fine for nodes related to parties, but what about relationship activation, de-activation, and update? For example, what if the user requests that two existing parties be connected through the HAS_APPOINTMENT relationship? We could send back a URI that could theoretically lead to you the relationship, e.g., /relationships/{id} but would that be useful to the app? Does it leak too much implementation detail?

New nodes to model: :DMORequest, :DMODecision, :DMOComment

Questions. If the DMO has a question for the user, we could handle it completely offline; that is, just contact the user via Slack, email, or a phone call. Alternatively, we may decide we want to keep the conversation as part of the stewardship history for the record. This would be a future enhanncement.