Documentation Index

Fetch the complete documentation index at: https://support.lusid.com/llms.txt

Use this file to discover all available pages before exploring further.

Managing configuration resources and data

Prev Next

You can use the Data Management dashboard in the Admin Portal to:

  • Deploy configuration resources to domains (see below).

  • Replicate domains (coming soon).

Understanding LUSID configuration resources

Configuration resources are the transaction types, property types, data types and so on that drive the FINBOURNE platform. See a full list of resources.

You can bundle configuration resources into one or more packages for deployment to target domains. For example, you might use the Admin Portal to create:

  • A core_ibor package containing transaction types and sides to generate holdings with a particular economic impact.

  • A quote_outliers package containing task definitions, workers and workflows to automate a data quality check.

  • A broker_feed package containing schedules, jobs, Drive files and entitlement policies to automate a transaction data load.

Each package is a JSON file that describes a desired state. When you use the Admin Portal to deploy a package to a target domain, LUSID infers how to create, update and delete resources in that domain to match the state. Deploying the same package to multiple domains guarantees a consistent result. Note the Admin Portal integrates source control applications (Gitlab and Github) to facilitate change management and recovery of package files.

Resources successfully deployed by the Admin Portal become managed resources in the target domain. Note not all resources in a domain need be managed:

  • If a resource (for example, a transaction type) is deployed and does not exist in a target domain then it is created as a managed resource.

  • If on a subsequent deployment of the same package a managed resource is found to differ then the target domain is updated to match the desired state.

  • If a managed resource is omitted from a subsequent deployment of the same package then it is deleted from the target domain.

  • If a resource is found to already exist in the target domain (in an unmanaged state) then the deployment fails with an error.

Note the Admin Portal flags some resources (for example, transaction types and property types) as having dependencies (sides and data types respectively). You must include dependencies in a package but in most cases you can choose whether they are deployed as managed resources or as references. LUSID checks whether references exist in the target domain but does not update or manage them (if they do not exist, the deployment fails with an error).

Example: Deploying transaction types and sides

Consider the following example, of a target domain with an existing set of unmanaged transaction types and sides, perhaps built-in to LUSID or created by users:

We want to deploy and subsequently manage two additional transaction types, which between them have dependencies on three sides:

We can create a package in the Admin Portal with a deployment ID of core_ibor containing:

  • BuyBond and SellBond transaction types and a CarryAccrual side as managed resources (in blue).

  • Side1 and Side2 as references, since they already exist in the target domain and we do not want to manage them (in red).

When we deploy the core_ibor package from the Admin Portal:

  • BuyBond, SellBond and CarryAccrual are created in the target domain, since they do not already exist, and are labelled as managed resources (in blue).

  • LUSID checks that Side1 and Side2 exist but does not label them as managed (in black).

  • The existing Buy and Sell transaction types are untouched.

If we subsequently edit core_ibor to remove the SellBond transaction type:

The next time we deploy, SellBond is removed from the target domain:

Best practice recommendations

Note the following:

  • The Admin Portal does not track resources between packages. The recommended approach is to only ever include a managed resource in a single package. The same resource can be included in other packages as references.

  • Do not attempt to deploy system resources such as property types in the protected system, internal and default scopes (for example, Transaction/default/GrossConsideration). This causes the deployment to fail with an error.

  • Where the Admin Portal flags system resources as dependencies (for example, the system/string data type for a custom property you want to deploy), they must be included in packages as references. If included as resources, the deployment fails with an error.