Pub/Sub Manager

The Pub/Sub manager allows administrators to control the Publish / Subscribe Architecturesubscriptions registered in the iCDR instance.

Subscription List

The publish/subscribe manager shows a list of all registered subscriptions. This view allows administrators to quickly enable or disable outbound subscriptions from the iCDR or dCDR instance.

The commands on this screen:

  • Create - Allows administrators to create new subscription definitions with the related endpoint information.

  • Edit - Change the settings of an already registered subscription definition.

  • Enable / Disable - When a subscription is active, it is sending data out to the configured endpoints, when the subscription is inactive the subscription is registered, but will not send notifications. The enable/disable button permits the administrator to change this setting.

  • Delete / Un-Delete - Allows an administrator to remove a subscription, and to restore it.

Creating/Editing a Subscription

When creating a subscription the administrator will be prompted to enter settings related to the subscription which is being created.

Subscription Metadata

Subscription metadata is used to describe the subscription to other administrators using the iCDR solution.

  • Name - A unique named identifier for the subscription which appear in logs

  • Description - A short description of the subscription, its purpose, why it exists.

  • Support Contact - The person who should be contact when/if the subscription fails.

Subscription Filter

Next, administrators should specify the criteria under which the notification is triggered.

  • Applies To - The resource which this subscription applies to

  • Event(s) - The persistence events when the recipient should be notified

  • When Criteria - The filters for new events which should be applied when new data is received. These dictate when the recipient will be notified.

Preventing Bouncing

Sometimes when a SanteDB product notifies an external party of a registration of an event, the notified party will respond back with updates it would like to perform. In this scenario, we do not want the SanteDB server to re-send the object back to the system which made the change.

To prevent this behavior, filter the subscription based on the principal/application that last created the version of the object. For example, if the API key of the object which is the target of the notification is APP_THAT_SENDS_STUFFwe can instruct the pub/sub layer to prevent sending any updates received by APP_THAT_SENDS_STUFFto the application:

Endpoint Settings

The endpoint settings are used to control how and when the messages are sent to the remote endpoint.

  • Not Before - The date/time when the endpoint should start receiving messages from the iCDR

  • Not After - The date/time when the endpoint should stop receiving messages from the iCDR

  • Endpoint - The remote endpoint (url) where the notification dispatches should be sent

  • Dispatcher - The dispatching class to be used for formatting messages and authentication with the remote endpoint.

  • Custom Settings - Key/value pairs which are passed to the dispatcher to control settings related to authentication, message formatting, etc.

Dispatchers

fhir-message

Send messages using FHIR messaging (a message bundle with content)

  • Content-Type - Controls the format with application/fhir+xml sending XML format messages and application/fhir+json sending JSON

  • MessageId - Controls the message identifier sent in the FHIR message

fhir-rest-hook

Send messages using FHIR REST operations such as POST, PUT, DELETE.

  • Content-Type - Controls the format with application/fhir+xml sending XML format messages and application/fhir+json sending JSON

hl7-pat-id-source (SanteDB 3.x)

Sends LLP messages to a remote HL7v2 receiver using ADT^A01 , ADT^A08 and ADT^A40 (optionally ADT^A38)

  • MSH8 - The MSH8 security setting to be used

  • Transport - sllp to use secure LLP and llp to use unsecure llp

  • MSH34 - The MSH3 | MSH4 to send (default is the SanteDB server's)

  • SendAs - Client if sending ADT^A01, ADT^A08, ADT^A40 messages, or Server if using ADT^A38

Authenticator Flows

The HL7 FHIR integrators can leverage a dispatch authenticator implementing a IFhirClientAuthenticatorimplementation. By default, SanteDB ships with an OAUTH authenticator which allows the FHIR dispatcher to reach out to an OAUTH service to obtain a token prior to issuing the FHIR message request. To enable this, add the following properties to your channel configuration

Setting
Value
Description

$authenticationProvider

oauth

Sets the authentication provider to OAUTH

$oauth.server

URL

The base URL to the OAUTH server. The provider will use this value and attempt to obtain the .well-known/openid-configurationfile from the path

$oauth.client_id

String

The client identifier to pass in all requests

$oauth.client_secret

String

The client secret to use on the OAUTH server

$oauth.grant_type

passwordor client_credentials

The grant type to use for the issuing of requests to the server. This is how the sending SanteDB server authenticates itself to the remote

$oauth.username

String

When using a password grant, the username to authenticate as.

$oauth.password

String

When using a password grant, the password to authenticate as.

$oauth.scope

String

The scope names which the SanteDB server should request when sending data to the server.

$oauth.novalidate

True or False

When set to True the issuing SanteDB server will not attempt to validate the token passed back from the issuing server.

Related Topics

FHIR SubscriptionsDispatcher Queue

PreviousLogsNextServer Status

Last updated

Was this helpful?