Introductie

Output Management verzorgt automatisch de notificatiepatronen voor de volgende scenario's:

• Zaak aangemaakt (ontvangstbevestiging)\

• Zaak bijgewerkt (status wijziging)

• Zaak afgesloten

• Taak toegewezen

• Besluit genomen

• (Berichtenbox) bericht gemaakt

Voor deze patronen weet OMC welke registraties er bevraagd moeten worden; authenticeert zichzelf; en vraagt de details op. Ook weet OMC voor elk patroon welke condities er vervuld moeten zijn voordat er een notificatie verstuurd moet worden.

Not Implemented

A special fallback scenario which only role is to report that the provided "initial notification" or conditions are not sufficient to determine a proper OMC scenario - to be resolved and used for processing the business logic.

User can expect meaningful API response from OMC. This response will have HTTP Status Code (206) that will not trigger Open Notificaties Web API service to retry sending the same type of "initial notification" again (which would be pointless and fail again since the OMC scenario or new condition are not yet implemented).

OMC Scenarios

OMC "Scenarios" are specific processing workflows, set up in the code to handle certain business requirements: what, when, how, and which to process the "initial notification" received from a subscribed channel from a message queue implemented by Open Notificaties Web API service.

Using environment variables such as "Domains", "Whitelists", "TemplateIds", and most importantly "OMC Workflow version", the user of OMC can have some control:

• what external third-party Web API services will be used (domains)

• when the specific notification will be processed (whitelists)

• how the recipient will see the notification (template IDs), and

• which internal implementation will be used (OMC Workflow version)

Implementation of new business cases, obviously(!), requires ingeretion in the code (C#) and preparing new OMC scenarios and the processing logic (validation, conditioning, settings...).

Currently, the following business scenarios are implemented:

• Opening a case

• Updating a case status

• Closing a case

• Assignment of a task

• Receiving a decision

• Receiving a message

Notification

Any OMC workflow relies on receiving the (initial) notification event from Open Notificaties Web API service to trigger the processing business logic.

This notification is in JSON format.

Except of being awaited by OMC callback ([OMC]/events/listen endpoint) it can also be passed from outside to HTTP Requests while using Swagger UI or Postman - to test or simulate the desired OMC behavior. This way the initial event from Open Notificaties Web API service can be stubbed.

Using Swagger UI is recommended solution, because of its user-friendly User Interface, documentation of endpoints, parameters, remarks, JSON examples, model schemas, and validation; formatting of API responses is also better than in Postman.

Environment variables

To work properly OMC always requires these mandatory environment variables to be set:

NOTE: If some environment variable is missing but required by one of the countless scenarios, conditions, or workflows, the OMC application will return a readable and user-friendly API response with the name of the missing environment variable. This is the easiest way to figure out what else is required.

ASPNETCORE_ENVIRONMENT

Used by [OMC]/events/version endpoint and to determine which appsettings[.xxx].json will be used.

OMC_AUTH_JWT_SECRET

OMC_AUTH_JWT_ISSUER

OMC_AUTH_JWT_AUDIENCE

OMC_AUTH_JWT_EXPIRESINMIN

OMC_AUTH_JWT_USERID

OMC_AUTH_JWT_USERNAME

Required to get access to OMC and be able to use it. Moreover, Open Notificaties Web API service will use this method to make an authorized requests while sending notification events to OMC.

OMC_FEATURE_WORKFLOW_VERSION

Without this setting (the version needs to be supported) the OMC Web API will not even run and specific implementations of underlying services will not be resolved by Dependency Injection mechanism. By default you can always use "1" if you don't know yet which other OMC Workflow version you should use.

ZGW_AUTH_JWT_SECRET

ZGW_AUTH_JWT_ISSUER

ZGW_AUTH_JWT_AUDIENCE

ZGW_AUTH_JWT_EXPIRESINMIN

ZGW_AUTH_JWT_USERID

ZGW_AUTH_JWT_USERNAME

JWT authorization is required by some versions of external API services used in certain OMC Workflow versions.

ZGW_AUTH_KEY_OPENKLANT => Required only in certain OMC Workflow versions

ZGW_AUTH_KEY_OBJECTEN

ZGW_AUTH_KEY_OBJECTTYPEN

API key authorization is required by some versions of external API services used in certain OMC Workflow versions.

ZGW_ENDPOINT_OPENZAAK

ZGW_ENDPOINT_OPENKLANT

ZGW_ENDPOINT_BESLUITEN

ZGW_ENDPOINT_OBJECTEN

ZGW_ENDPOINT_OBJECTTYPEN

ZGW_ENDPOINT_CONTACTMOMENTEN

Endpoints might have different paths (e.g., domain/something/v1/) depends on version of external API service used in certain OMC Workflow. For example domains for OpenKlant and ContactMomenten depends on version of Open Klant Web API service. Moreover, domains and paths depends on the place where your version of Web API service was deployed (domain) and the way how it is internally structured (paths).

NOTIFY_API_BASEURL

NOTIFY_API_KEY

Values required to initialize Notify HTTP client.

These environment variables are optional:

SENTRY_DSN

SENTRY_ENVIRONMENT

Logging and analytics in third-party service (Sentry.io).

5.2.1.3. Requirements

To process certain notification the specific internal criteria must be met. Usually, they are some pre-validation (analyzing the "initial notification" received from Open Notificaties Web API service), post-validation (to determine the scenario suited for this type of the notification), and whitelisting steps (to ensure that OMC should continue processing this type of notification). Sometimes, additional checks have to be performed - which depends on the specific OMC scenario.

5.2.1.4. Template placeholders

When everything is already validated, prepared, and processed, the Notify NL Web API service needs to receive instruction how to format the upcoming notification. The way how to achieve this is to set up so called "template" (using Notify NL Admin portal webpage), define ((placeholders)) in the text (subject and/or body) - matching to the ones defined by the specific OMC scenario, and then use the ID of this freshly generated "template" in respective environment variable for OMC.

5.2.1.5. Parties and preferred addresses

Once the parties have been identified, the next step is to select a method and address for contacting them. The first selection is based on the case identifier (V2 CaseDetails Identification). If an address exists that matches the case identifier, it will be used. If no match is found, the system will check for a preferred address. If neither a preferred address nor a case identifier match is found, the fallback address will be used.