Zekt Directory

Zekt Directory - is the marketplace, where a zekt-provider (of workflows) can “publish” their services simply by listing it in the directory. Once listed - zekt-consumers, can search and request access to the service and consume the events generated by the providers workflow.

Zekt Directory - conceptual

As we have learnt, zekt-providers (omit events + optional message payloads) & zekt-consumers (digest events and the corresponding messages). Well - the Zekt directory acts as the marketplace, where a provider can choose to (active decision / not enabled by default / zekt member decides / no extra cost) publish their workflow (the service) to a global audience of potential Zekt consumers!

Once a customer - finds a service, to which they want to subscribe - they can request access to the service (e.g provider workflow) from the zekt management tool. Within the same tool, the zekt provider owning the service - will get alerted, that a request has been sent to them where they can then either approve - or deny the request. As soon, as the consumers request has been approved by the provider - zekt will start brokering the events coming from the provider to the approved consumer(s).

NOTE: A provider does not have to publish their workflow to a global audience using Zekt directory while still being able to collaborate with other teams.

Service description(s)

When a provider wants to offer a workflow within a repository - for which they are in control of - to a broader audience, they will list the service in the Zekt directory. In order to do so, they will need to package/present the service by creating a “service description”. The provider will “package” the workflow - behind a “service description”, making it easy to “understand to the consumers”, as-in:

Service description:                            Owner:
----------------------------------------------------------------
"New cool sneakers have arrived in the store"   "the sneaker dude"

If you as a consumer, is super into new sneakers, this service offering might be something for you to request access to. Anyway - this address two concerns. Many times, the github username, is some strange user-name, and does not represent the company or organization, that wishes to offer the service to the public. As such, abstracting away the “github username” to the consumers is important. Likewise, just as important it would to be able to “present yourself in a correct manor” using your corporate name or similar. Below are a couple of more realistic scenarios:

• Example #1: Use the directory
• Requirement: Both teams, are acting as zekt-providers & zekt-consumers
• Scenario description:

A financial services team - has a process defined which requires - that each time a certain workflow fail - they need an external auditing team to investigate conditions. If no raise conditions were found by the auditing team - they need to send “proceed” to the financial team, so that they can process the next transaction.

The finance team would create a “service description” as:

Service description:                          Owner:
----------------------------------------------------------------
"Financial transaction verification failed"   "the finance team"

The auditing team would create a “service offering” as:

Service description:                          Owner:
----------------------------------------------------------------
"No raise condition found. Proceed."          "the audit team"

• Example #1: Use the directory
• Requirement: One team is acting as consumers, the other team providers
• Scenario description:

When the sales team has finished their aggregation of forecast figures, have the internal finance team review the figures!

Sales team would create a “service description” as:

Service description:                            Owner:
----------------------------------------------------------------
"Forecast figures - analyze stock indications"  "the sales team"