Manage service versions and effective dates

In Spark, after an Excel file has been uploaded to Spark and the logic is converted to code, it is referred to as a service. Multiple versions of a service can be added to an existing service, called service versions.

In Spark, each service version can have customized effective start and end dates for each service. This enables the capability for Spark to serve the different service versions of 1 service based upon a date input.

Define effective start and end dates for a service version

Choose effective dates for a new service or service version

• When an Excel file Create a service or Add new version is performed in Spark, modals will offer an option to modify the effective dates.

• By default, the effective start date is set to the upload date. The effective end date is 100 years into the future.

• These dates can be modified to align with the start and end dates for a particular calculation change.

• Dates and times are defined in the local time of the logged in user. Check the detected time zone in User menu.

Edit effective dates and times

• See Modify a service property.

Resolve service versions

How versions are specified in the Execute API (v3) is explained in the request_meta. The same applies for Execute API (v4) but instead of transaction_date, the name of the parameter is version_by_timestamp.

The behaviour can be summarized as follows:

• If a specific version or version_id is being called by the API will ignore the transaction_date.

• If the transaction_date is specified and no version is specified, it will use the latest version that applies at the time of the transaction_date.

• It is important to note that that the Execute API will always resolve the version_id parameter first, service_id parameter second, and then service_uri last. It is possible for an API request that these 3 may refer to different services entirely but Spark will resolve the reference in the same order.

Invocation method	transaction_date	Version resolution
version_id	has no impact on version resolution	Will use the version specified by the API call.
service_id or service_uri	none provided	Use the latest version that applies where the transaction_date equals the current time.
service_id or service_uri	user provided	Use the latest version that applies at the transaction_date. If the transaction_date is outside of the Effective Dates for any services then no calculation will be returned.

This functionality cannot be tested within the API Tester as it is service version specific. Use the Postman to try out the functionality with an API request.