Calypso Technology

Technical Training
Day 5
Agenda

• Reporting Framework
• Position keeper
• Administration
• CalypsoML
• CAM Tool
Reporting Framework
 Reporting Framework Elements

The Reporting Framework API consists of a collection of GUI and Toolkit classes that are used
to build custom reports or customize and extend existing reports.
• Report Template — The input parameters for the report.
• Report Template Panel (GUI) — Panel for the input parameters of the report.
• Report — Executes the database query to retrieve the data.
• Report Panel (GUI) — Panel for the report output.
• Report Output — The controller that sorts, formats, and aggregates results of the
report.
• Report Style — Utility to extract atomic values and describe the columns of the Report
Output.
• Report Viewer — An interface to “render” or display the report output to the end-user.
• Report Row — Stores the data for each row in the report.
• Report View – An interface to “customize” the way Report Viewer displays its data
• Report Window (GUI) – The main report window that drives all reports
• ReportWindowCustomizer (GUI) — used to add menus and features to a report
 Report Components

Given the argument passed to the Report Window (e.g. “Posting”), several GUI and other
toolkit classes will be instantiated and attached to the Report Window. It is not
necessary to create a unique window for each report.

ReportWindow (GUI) + PostingReport + PostingReportWindowCustomizer (GUI)

PostingReportTemplatePanel (GUI)
+
PostingReportTemplate

ReportPanel (GUI)
+
ReportViewer(I), ReportView
+
PostingReportOutput
+
PostingReportStyle
+
Trading Book ReportRow objects
Also:
Hierarchy
•PostingReportTemplateListener
•ReportPostingHandler
ReportOutput Class

ReportOutput

The core class that “handles” the report output is ReportOutput.

• Sorts the rows based on the SortColumns.
• Parses through each row and calculates the subtotals and totals
• Passes the information along to the ReportViewer.
• Does not render or display the data. This task is left to the ReportViewer class.
• Arranges the report data as set by the report with the setRows() method
• Compatible with the parameters given in the ReportTemplate (Columns,
SortColumns,Subtotals, etc.)
•Most reports may rely on the DefaultReportOutput class
ReportTemplate Class

ReportTemplate

The ReportTemplate class provides the means to save report queries to the database.
It is a container class composed of a hash table that stores the selection criteria that
creates the SQL statement used to retrieve the report rows
•Defines items to be placed in the ReportTemplatePanel
•Can be used to set the default columns
•ReportTemplate is serializable and a unique serialVersionUID should be created
for each template.
Report Template Panel

ReportTemplatePanel

The ReportTemplatePanel provides the GUI to receive and display the data managed
by the by the ReportTemplate class
The following two methods must be implemented:
•public abstract void setTemplate(ReportTemplate template);
-responsible for displaying a template’s set of data to the GUI,
public abstract ReportTemplate getTemplate();
- returns the values from the GUI to the report template.
This panel, once compiled, will automatically be loaded and inserted at the top of the
ReportWindow.
If a ReportTemplatePanel is not implemented for a specific Report, the
ReportTemplate will be displayed using the DefaultReportTemplatePanel which
provides a simple GUI and lists most of the parameters in tabular format and does not
provide any kind of type-checking.
 Report Class

The Report abstract class builds the query based on the input parameters found in the
ReportTemplate.
The process is instantiated by the report name – i.e. ‘Posting’Report
The data retrieved from the query gets packaged into ReportRow objects that will be
used to display the report.
What gets returned is a ReportOutput with a set of rows (ReportRow objects), which
encapsulate the data retrieved from the system on a per-row basis.
The ReportRow object allows associating multiple objects. A Message Report, for
example, could have a message, a transfer, and a trade all associated with the same
ReportRow.
It is here that we perform the load from the database and set the raw data up in the
ReportRow class. While there are many methods that may be overloaded to control
aspects of the report the only method that must be created is
public ReportOutput load(Vector errorMsgs)
The load method gathers the report data and sets it into the ReportRow objects.
The rows are then loaded into DefaultReportOutput object and the framework passes
that class around with the ReportTemplate to the ReportStyle class where the data is
massaged/extracted for the report columns.
ReportStyle Class

ReportStyle

The ReportStyle class is a helper class which provides the functionality to establish
the report columns and to extract column values from ReportRow objects.
Columns are described in ReportStyle by creating a series of static String variables
to represent the columns of the report. The exact string created will be the initial
column’s names. Example:
public static final String TRADE_ID = “Trade Id”;
public static final String VAL_DATE = “Valuation Date”;
Besides defining the column names, the ReportStyle is responsible for returning the
column value. The column value is always returned by the routine:
public Object getColumnValue(ReportRow row, String columnId, Vector
errors) throws InvalideParameterException {}
The ReportStyle class is extensible. There’s no need to “duplicate” the
functionality to extract a column value. By extending from a superclass, you inherit
this behavior.
Report Row Class

ReportRow

An object of the type ReportRow is made for every returned row from the database.
Each ReportRow object is a specialized hashtable of related objects from which to
derive the data for the visable row in a report.
A ReportRow encapsulates one or more Calypso objects. From the object, it is necessary
to “extract” a column value, either because the column is a direct mapping to an object
field value (for example the TRADE_ID column maps to Trade.getId() method).
The data passed in as a ReportRow is returned By the ReportStyle class using the
getColumnValue() method.
If you create a new report that uses data other than those described in the ReportRow
class, you should add your new type to this class. It is important for report inheritance
(reports that are build atop other reports) that the ReportRow class remain complete.
 Report Classes Execution Sequence

Bringing it all together via the ReportRow object:

The load() function of the Report class has access to the ReportTemplate though the
variable _reportTemplate.
The load() function should extract the filtering parameters from the _reportTemplate
and do the necessary database accessing to obtain the data for the report rows.
Once the data is obtained (may be several objects per row) the rows are created and
loaded into the ReportOutput object which is the return parameter from the load()
method.
This data now stored in individual ReportRows as an array which is set back to the
ReportOutput object. The ReportRows are then extracted and sent to the
getColumnValue() method of the ReportStyle for each column of the report display.
 Advanced Options Classes
There are other classes that are handlers, listeners, and customizers that add additional
features to reports. Some of these are:
The ReportWindowCustomizer class provides the ability to extend the Report Windows
popup menu, provide a warning before the report closes, customize the report window,
define right-click menus and allow for editable fields which can be written back to db.

ReportWindowCustomizer
applyCustomMenuToAllRows()
callAfterLoadAll(ReportWindow)
callBeforeClose(ReportWindowDefinition)
customizeReportWindow(ReportWindow)
getCustomMenu(ReportWindow)
ReportPanelListener
callAfterDisplay(ReportPanel)
callBeforeLoad(ReportPanel)
handleRowSelection(Object)
isValidLoad(ReportPanel)

ReportRealTimeHandler
getRealTimeClassNames(ReportPanel)
handleEvent(PSEvent)init(boolean)
isEventProcessingNeeded()
processPendingEvents()
 Registering a New Report
A new report has to be added to the “REPORT.Types” domain, without the ‘Report’
suffix: For example, the FXProductReport class is added to the domain as ‘FXProduct’
In MainEntry > Help > Main Entry Configurator, add the report to a menu as follows:
Name: FX Product Report
Action: reporting.ReportWindow$FXProduct
$ signifies a paramater to the Framework class, # signifies the default template
Report Exercises
Agenda

• Reporting Framework
• Position keeper
• Administration
• CalypsoML
• CAM Tool
Position Keeper
Position & Risk >Positions ( Window )
Position Keeper - Preparing

Generating Positions
• In order to view positions in the Position Keeper, the Liquidation Engine
must first generate them. The following steps are required for position
generation:
• The Transfer Engine must be running.
• The Liquidation Engine must be running.
• To be included in the positions, trades must advance to the VERIFIED
status.
Position Keeper – Features
Val Date
The date on which you will view the positions. If the date is today, then you will see the positions as of now. If it is for an earlier day,
you will see the positions as of the end of the day. If you want to load a past position, unclick the flag Real Time on the left-bottom
hand, then choose the past date/time.
Trade Filter
This window will display positions made up of only the trades in your trade filter. To define a filter go via the Main Entry window >
Static Data > Reference Data > Trade Filter.
Pricing Env
The Pricing Environment containing the Quote Set that will be used to compute your P&L position. Closing prices (instance = Close)
will be used from this Quote Set. To create a Pricing Environment, go via the Main Entry window > Market Data > Pricing
environment.
Hierarchy
The Book Hierarchy used to filter your positions in this window's display. Selecting a Book Hierarchy is not mandatory. When you
select a hierarchy, it will appear as a tree view in the pane occupying the left side of this window. Each node generally corresponds to a
part of your organization or types of trading you do. To dis­play the positions of any node in the hierarchy, click on that node in the tree
view.
To define a hierarchy, go via the Main Entry window > Static Data > Reference Data > Book Hierarchy.
Aggregation
The user can display his position aggregated by attributes of books in the selected hierarchy. (Attributes are defined in the Book
window)
Real Time
This check box indicates whether you will receive real time alerts if the market data or other data in the Pricing Env change.
Position Keeper – Exercise

 § file : E_Position_management.doc
Agenda

• Reporting Framework
• Position keeper
• Administration
• CalypsoML
• CAM Tool
Admin Monitor
 The Admin Monitor application allows IT staff to observe all activity in
Calypso from a system perspective.

Utilities > Maintenance > Monitoring > Admin Monitor

Admin Monitor -- Events
Admin Monitor -- Archive
 Don’t not use in production, use scheduled task instead
 Periodically trade data that has matured should be archived from the main database
tables
Admin Monitor -- Cache

 One cache by object – Free implementation

Admin Monitor – Engines
 e.g : MAX_BATCH_EVENTS, MAX_QUEUE_SIZE
Admin Monitor – SQL Statement

 High treatment batch : e.g : InventoryEngine

Admin Monitor – ExecuteSQL
Admin Monitor – Monitoring
Monitoring -- Watcher

 E.g : Send email when DS Memory breached a threshold

Utilities > Maintenance > Monitoring > Admin Monitor > Admin > Watcher configurator
Troubleshooting

 DataServer runs slow

 Long pauses in operation
 Generating thread dumps
Windows
Unix
 Tracing GC operations
 Tracing bottlenecks
 System Performance has degraded
 The most common reason for overall system performance
degrading is that the the DataServer is taking longer to respond
to requests than normal.
Exercices

 Hands on trade entry

 Monitoring…
Agenda

• Reporting Framework
• Position keeper
• Administration
• CalypsoML
• CAM Tool
CalypsoML

• Introduction

• Exporter/Importer Application

• Calypso XML schema

• JAXB Binding File

• JAXB Translators
CalypsoML

XML Document

Marshal

UnMarshal

Calypso ML allows Calypso objects to be marshaled into XML documents and vice
versa.
CalypsoML composition
 XML Schemas to provide rules for constructing JAVA objects

 A pair of translators for each object that translate from JAVA to

JAXB and from JAXB to JAVA.
Exporter application
Calypso Schema

The schemas define what fields are required and what types those fields
can be.
Importer application

 Only XML documents validated by the Calypso schema can

be imported.
 The schemas ensure the XML document has the correct
format.
How to Extend Calypso ML?

1) Create the schema

2) Create the Java object through standard API
3) Add the schema to the binding file
4) Modify an ant task to perform the compilation (xjc)
5) Create a pair of JAXB translators
Create schema

 Each schema must define a target namespace.

 Use include for schemas with the same target
namespace.
 Use import for schemas with different target
namespaces.
Add the schema to the binding file
Create a pair of Translators

Java JAXB

• Translate( Object, Object) where type checking on the Objects takes

place and errors are recorded in the handleErrors() method

• BuildNew() contains getConfiguration().getFactory.get<JAXB objct>()

• Translate( Calypso java object, JAXB object ) where the actual

translation takes place
Translator example
Translator example
Configuration files

 JAXB Configurations defines which translator to use to translate a given object

 Persistence configurations provides the Calypso Session with save or delete

or load fonctionnality

default-exporter-config.xml
default-importer-config.xml
Summary

 CalypsoML consists of schemas and pairs of JAXB

translators

The Exporter/Importer applications allow marshaling and

unmarshaling of Calypso data

 CalypsoML is easily extensible through the Calypso API

CalypsoML : Exercices

1 – Import/Export the trade object throught the MainEntry

2 – Create a trade keyword validator before saving a trade :

- Indication1 : TradePersistenceSession
2.1. create CustomTradePersistenceSession who inherit
from TradePersistenceSession with an additional keyword
2.2 This custom class save trade with an additional keyword

3 – Change the identifier object of the Country from ID to

ISO_CODE
Agenda

• Reporting Framework
• Position keeper
• Administration
• CalypsoML
• CAM Tool
Calypso Technology

The End