Rosetta Translate ¶

Rosetta Translate enables the user to keep in control of a mapping layer between their existing systems, databases and message formats and the format underpinned by a model. The main artefact of the mapping layer is called the Translation Dictionary, which is created thanks to Rosetta Translate.

Rosetta Translate is closely linked to another Rosetta product: Rosetta Ingest. Rosetta Ingest offers an universal API to ingest and normalise the user data, by leveraging on the mapping layer that is created thanks to Rosetta Translate.

In this section, you will learn about:

• Ingestion and Projection
• Exploring the file
• Uploading a file
• Running Ingestion
• Viewing the results

This section uses examples extracted from the ISDA CDM, which is an industry model for which a rich set of mappings has been implemented. Users are invited to refer to the Mapping Section of the Rosetta DSL documentation for further details on how mappings are implemented.

Ingestion and Projection ¶

In Rosetta, Ingestion is the process of converting an (electronic) input file into the format underpinned by a model.

The input file can be one of different standard formats for electronic data storage and transport, such as XML or JSON.

The model output can be:

• An electronic file, using the same range of support formats as the input file (a.k.a. a Serialised model document)
• A model object that computer code can be directly executed on (a.k.a. a De-Serialised model object)

The Serialised view is useful to display the model output into an interface, in a way that a user can browse through and understand. This is the view that is used when demonstrating how Rosetta Translate really works. The De-Serialised object is not meant to be readable.

Conversely, Projection is the process of converting a model object into an (electronic) file with the targeted format.

Exploring the files ¶

The File Explorer allows the user to interact with sample files which are specific to the loaded Workspace.

File Explorer overview ¶

Filter Bar ¶

The Filter Bar provides the ability to limit which files are displayed.

The Filter Bar is made up of the following components:

• Synonym Sources: Use this drop down to view only sample files that run against a particular synonym source
• Show Results: Checking the checkbox will only show sample files whose tests have been run and have results to display
• File Name: Enter text here to filter by sample files whose name contains that text
• Run Button: Select to run all files in the current filtered view, this button also shows the number of results

File Upload ¶

The Upload button allows users to select sample files from their desktop and store them either on the server or in their browser on their computer. The decision to store on the server or not depends on whether the Upload to server checkbox beneath the Upload button is ticked.

File Explorer View ¶

The File Explorer View is split up into Group Rows and Sample File rows.

Group Rows ¶

The Group Row hierarchy structure is dictated by the location of the sample files within the model and their purpose is a logical categorisation of the various sample files.

The Group Row is made up of three components:

• Group Name: Sample file group name.
• Synonym Source: The oval synonym source marker shows which synonym sources are used by each of the sample files in that group.
• Group Status: The group status pie chart shows how many files have been run in this group and what percentage of them were successful.
• Group Completeness: These three pie charts show the individual mapping, validation and qualification success percentages.
• Run All Action: Runs all sample files within the group.

Sample File Rows ¶

The Sample File Rows allow the user to interact with each sample file associated with one group, trigger test runs, view run summary information and navigate to the detailed analysis page.

The Sample File Row is made up of the following components:

• Diagnostic Summary: This summary shows a pie chart with the percentage success calculated against an expected value for each of the following:
  • Mapping: These are are the number of paths in the source file that have mapped successfully to paths in the selected model.
  • Validation: This result shows what percentage of validation rules passed for the qualified type.
  • Qualification: A qualification is the type that an ingested source is assigned having passed a set of criteria in a qualification function.
• Detailed Diagnostic Summary: When hovering over each of the diagnostic summary charts described above, each of these popup summaries contains the following:
  • Success: The actual vs expected success count for that result type.
  • Failure: The actual vs expected failure count for that result type.
  • Excluded: The actual vs expected excluded count for that result type.

• Rerun: The rerun buttons appear when the results have gone stale due to a model change and allow the user to refresh the results.

• File Run States: Here are all the row states:
  • Pending rows will have a grey background
  • Successful rows will have a green background, all their expectations have passed
  • Failed rows will have a red background and mean that the file has failed to pass the expected Ingestion tests
  • Warning rows will have a yellow background and mean that an error occurred when running the Ingestion
  • Stale rows will have a grey background

Case for Uploaded File Rows ¶

Uploaded files have a slightly different view as outlined below. An uploaded file does not have any Diagnostic Summary, and, consequently, any Detailed Diagnostic Summary. This comes from the fact there are no expectations to compare the results against for these file types, unlike for Sample File Rows. The user can still interact with these rows to run and rerun in the same way as Sample File Rows.

The Uploaded File Row contains the following components:

• Synonym Source Selector: This allows a user to change which synonym source to ingeste a file against
• File location icon: Files which have been stored on the server display the cloud icon

Uploading a File ¶

To upload an electronic file for Ingestion click the upload button and select the file from the popup. Before uploading the file the user can opt to save on the server by clicking the checkbox. This will mean the file will be present after logging in on a different computer.

During the upload process, the system will guess which synonym source to ingest the file against. But this can be changed by using the synonym source selector on the Uploaded File Row after the file is uploaded.

Running Ingestion ¶

Provided that all the required code in the user Workspace is ready to be run, the user can process one or multiple files through Ingestion by doing one of the following:

• Single File Run: Clicking on a Sample File Row will start the process of Ingestion, and a spinner will appear at the right end of the row
• Group File Run: Clicking on the Run Group button on a Group Row will start processing all sample files in that Group, and a spinner will appear next to all files subject to Ingestion
• Filtered Run: After applying a filter, the Run all files button will appear with a number of results. Clicking this button will start processing all results.
• Rerunning Files: If a file has not been processed or results have gone stale, the user can reprocess a file by clicking the rerun button. By contrast, a Group can be reprocessed at anytime by clicking on the Run Group button.

Viewing the results ¶

When a file has results, the user can click on a Sample File Row to open the Result Viewer.

Result Viewer ¶

The Result Viewer displays the results for a given sample file. It is split vertically into three panels, from left to right:

• Diagnostics panel: this pannel displays statistics (Mapping, Validation, Qualification) and other key information summarising the success (or failure) of ingesting the file.
• Input File View and Model Output View panels: these panels allow the user to review how the system has ingested the input file. The Input File View corresponds to the input file used for Ingestion and the Model Output View corresponds to the output in the model format.

View Modes ¶

The Input File View and the Model Output View have two view modes:

• Code View: displays the file in its original mark-up format
• Formatted Document View: creates a tree structure which is colour coded to indicate the result of the Ingestion process

The Formatted Document View uses a list of colours to give mapping information between the input file and the model output

• Red: Invalid or unmapped values
• Dark Green: Mapped values
• Dark Green With underline: Mapped and linked values from input file to model output
• Light Green: Conditional values
• Yellow: Excluded values
• Black: No mapping data for these values