Skip to main content

Introduction

The Subscription Service provides functionality that allows for the execution of scheduled and recurring workflows. In the context of the service, a workflow is defined as a business flow, simple or complex, comprised of a sequence of API calls to other services. For example - Collect a fee each month, after purchasing a device protection policy subscription, where a call to the payment provider’s API would take place, to perform the fee collection, followed by a call to the messaging service to notify the client of the charge.

The service enables the creation of custom workflow configurations (an Execution-Strategy), that may then be used to add behavior to each created Execution-Instance. Each Instance then spawns timed Events to be executed at a certain date, based on the configuration.

The base entities are, the Client is called Strategy, the Contract is called Instance, and the Event.

Strategy, where all the necessary settings reside, was entirely reorganized with two main concerns in mind:

  • Improved scalability and flexibility - This includes but is not limited to - Smaller configuration blocks, easier to write, read, and reuse; New tools and strategies that allow for the creation of intricate business flows, effectively removing the need to create code based controllers in the service’s source code; One-shot configuration, merging multiple configuration files, for multiple environments, into a single one;

  • Better security of sensitive information - Strategies, unlike the old Clients, are now secured on two levels. One - They are password protected, meaning only the owner may interact with a given Strategy. And two - They may be keep encrypted in the database.

That about covers all the changes that are visible to the consumers. Most of the old APIs were directly migrated into new versions, with only small changes to some nomenclature. Of course, most of the new APIs, those that involve the Strategy, now include an additional field - secret - to authorize the use of said Strategy.

Under the hood is where most changes occurred. To name the most relevant ones:

  • Multithread, multi-instance, multi-cluster, and sandbox support - Subscription Service may now be executed concurrently across different clusters, and multiple instances. Event execution may now also be sandboxed in a different process, allowing for multi-threaded processing and securing the main thread from crashing;

  • Comprehensive Syntactical and Semantical configuration validation - While the previous version only performed syntactical validation of its Client entity, the new version add a strong layer of semantical validation of its Strategy entity;

  • The queueing mechanism - Previously, events were scheduled to run on a given day, at any given time. Now events are scheduled to run at a specific datetime. A low-pooling system is still employed, but may now be set up to provide a more precise event execution, time-wise. Under normal load, an event may now be expected to execute within the minute it was scheduled to run.