Webhooks and Service Providers

A service provider contains the implementations for a set of capabilties. In other words, it contains the specific pieces of implementation logic for handling webhook requests for a set of capabilities.

A typical architecture is that the service provider acts as a gateway between Ocelot and the school's various systems. When the service provider connects to a single internal system and the count of specific pieces of implementation logics is manageable, a single service provider will be more than sufficient.

As a service provider grows the number of webhook capabilties it implements, different capabilities may require querying different internal systems. Connections to different systems may require different client SDK's, communication libraries or database drivers. The SDK's, libraries, and drivers may come into conflict with each other. Suppose that this were to occur. One resolution would be to implement multiple service-providers. Capability logic would be organized into groups for each internal system. The multiple service provider would be registered and simulateneously connected to the Ocelot API.

Another scenario is a long migration of an internal system. Suppose that a service-provider has already been built out for the original internal system. A second service-provider can be implemented with logic for the new internal system. It wuold be registered with a higher priority. The second service-provider can initially have fewer capabilities than the original service-provider. It can then be grown in a manner tracking the migration to the new internal system.