Introduction to Workspace¶
A workspace is a user area allowing the user to work with the model in a “safe space”. It contains a copy of all the model files for the user to edit and test within their own area.
The Workspace Manager is accessible via the Workspace Menu button at the top of the application window. This shows the current workspace name.
A workspace is typically designed around a unit of work that the user wants to carry-out, and named accordingly: in this instance, we signal that we are working on a “Demo”.
This introduction demonstrates basic workspace management tasks: creation, deletion and switching between them. Before proceeding, however, please note the following important fact about the application’s behaviour.
No Workspace Here…¶
Rosetta Core is a cloud-native application.
This means that the workspace exists not in the user’s local browser but on a remote server and simply rendered in their browser window. In particular, the model files are not stored anywhere on the user’s desktop and the user does not need to manage how these files are organised, nor configure dependencies, etc.
Similarly, there is no concept of “saving” a workspace in Rosetta Core: as the user makes changes, the state of the workspace evolves and the latest state gets automatically persisted on the server.
This cloud-based paradigm drives much of how the application behaves from the user’s perspective.
Opening and Switching Between Workspaces¶
Every Rosetta Core user manages its own set of private workspaces. A user may have multiple workspaces but they can only activate and use a single workspace at any point in time. The active workspace is loaded on the server that the user’s browser is connected to.
There may be some restrictions on the number of workspaces that can be managed concurrently, depending on the Edition of Rosetta Core being used.
Pressing the Workspace Menu button presents the user with the Workspace Manager:
When a user loads the application for the first time they will be directed first to the Workspace Manager. This will direct them to choose which of the standard readonly models they wish to use.
The Workspace Manager provides access to all the operations the user requires to manager their workspaces. It provides access existing standard read only models, allows the user to create their own models, switching between existing models and other actions such as downloading and deleting models.
When first opened a list of the currently available workspaces is displayed and the user can select which one to open:
When the user selects a different workspace (we switch from
CDM Latest to
Test in our example), the application closes the current workspace and opens the new one. This process typically takes a few moments as a number of server-side operations are required in the background. While this is taking place, the application is inactive and informs the user of progress:
The same workspace loading process must take place whenever the user signs into Rosetta Core or reconnects after a lost server connection.
Once its name gets displayed in the Workspace Menu, the new workspace has been loaded as per its last persisted state and the application operates in that workspace from now on.
Creating a Workspace¶
To create a new workspace, the user can select the “+” button or the “Create” button:
First-time users of Rosetta Core will be required to create a new workspace before using the application. They will be directed to the Workspace Manager straight after signing in.
In the following pop-up window, we create a workspace called “Tutorial” and give it the description of “ISDA CDM Tutorial”.
Once created, the application automatically switches to the new workspace and the user is ready to go:
Workspaces do not get created “from scratch”: as Rosetta Core is used to edit, test and potentially contribute back to the CDM, each workspace is attached to a specific version of the model, which must be selected at creation (
2.57.8 in the above example). When creating a new workspace, the server fetches all required model components from the CDM source-control repository and copies them into the user’s workspace area (a.k.a. Checking-Out).
The associated CDM version is displayed when hovering over the ‘i’ symbol next to the workspace name shown on the Workspace Menu:
Further details about version management or persistence into the source-control repository are provided in the Source-Control Integration section of the documentation.
Deleting a Workspace¶
Once the user is finished with their unit of work associated to a workspace, they may delete that workspace so that all the files are cleansed from the server. This operation is irreversible and the files will no longer be accessible once the workspace has been deleted.
Users are advised to save any work that they would like persisted into a source-control repository (a.k.a. Commit) before deleting their workspace.
Deleting a workspace can be actioned by pressing the bin icon next to that workspace:
It is not possible to delete the currently active workspace so there is no bin icon next to it.
Closing a Workspace¶
A workspace can get closed in a number of ways, voluntarily or unvoluntarily:
- when the user closes their browser window or tab
- when the user signs out of the application
- when internet connection is lost (e.g. when switching network)
Any of these scenarios are completely safe! All changes made by the user to their workspace prior to closure are automatically saved on the server and will be recovered when re-opening that workspace.
Source Control Integration¶
Users develop their model in Rosetta Core as a basis onto which system applications can be built.
In order to integrate their model output into such system applications, users must be able to share the content of their workspace with those systems’ source-control repository. There are currently two channels for doing so:
- Directly downloading their workspace content, to be then uploaded into another system’s repository.
- Contributing their changes to the CDM open-source repository, to be then used as part of another system build.
Further source-control integration features are planned for development and will be added to this documentation as they get delivered.
A user workspace contains model files, possibly edited, as well as executable code files (classes, libraries etc.) that are auto-generated from the model. Users can download these files from Rosetta Core using the download feature:
There are three options available:
- Rosetta: these are the source model files expressed in the Rosetta DSL syntax
- Executable code, currently available in two languages:
- Java: contains the
- Daml: contains the
.damlsource files and a
- Java: contains the
For more information about automatic code generation in Rosetta, please refer to the Code Generation section of the Rosetta DSL documentation.
Typically, a user may download the executable code files and use them as part of another system’s repository that is using either one of the available languages. The dowloaded files are packaged into a
.zip archive and unpacked into a file hierarchy that mimics how such files would be organised in a source-control repository:
Contribute Workspace Changes¶
The Rosetta source files themselves in the workspace may be used to contribute back to the CDM open-source project. This contribution feature has been fully packaged in Rosetta Core to directly connect via API to the CDM source-control repository, so it does not require any workspace download.
In this example, we are adding a condition to the
Create_SplitPrimitive function, to check that the sum of the break-downs in the
splitInstructions matches the original quantity:
This is a valuable condition to constrain the
Create_SplitPrimitive function for every implementor of the CDM, so the user wishes to contribute this change back to the CDM. The contribution functionality is accessible via the “Contribute” button next to the “Download” button:
Contribute button brings up the Contribute Workspace dialog allowing the user to review their changes. A split-view Modification mode is displayed. The files with changes are displayed on the left hand side. The modifications are displayed on the right hand side:
The user needs to provide a Summary (limited in characters) and accompanying Description for their contribution. This indicates the substance of their contribution to reviewers so it should be as concise and precise as possible. The user can then hit the
Submit command and the submission gets sent to the source-control API:
Once submitted, the proposed changes will be packaged as a Pull Request in the CDM open-source repository, ready for CDM reviewers to inspect. Note how the request is labelled with the Summary description (as provided above) and also gives the name of the user who submitted it, which helps reviewers identify the provenance of the proposed change.
If the contribution is accepted, the reviewer would merge the content back into the CDM master repository for a potential future release.
As new versions of the CDM get released on a regular basis, a future addition is planned to enable users to update their workspace to a more recent version of the model, while preserving their own changes (a.k.a. Merging).