Tag Archives: viewer

Tips

Datamart fun

6 Comments

Datamart is a great tool in Murex but it also quite confusing as to how to use it and make the most out of it. As always, your Murex consulting team is the best source of advice.

The process to produce reports is usually the following:

  1. Define Simulation view with the data you want to retrieve
  2. Define a Dynamic table based on that Simulation view (note that you could base a dynamic table directly on TRNRP_PL or TRNRP_CS for instance)
  3. Define a feeder on that dynamic table  (this will store the results into the reporting DB)
  4. Then use an extraction to retrieve the data from the reporting DB into a viewer.

The feeder can also source data from Murex tables or from other reporting tables. You’ll just have to build a map of the data you need and how to best access it. The feeders with SQL can retrieve data from different tables.

The advantage of using the simulation view as the source is that you can easily add fields and in a way do some WYSIWYG (what you see is what you get).

Now when designing reports, it is important to decide how frequently you would need to run the reports. For instance, if your feeders call upon other reporting tables, these ones won’t be refreshed. So re-running the reports on request is probably not always possible. Again it depends on your setup. If you’re simply sourcing from a dynamic table then it won’t apply to your case, but again each reporting setup is different.

Now one of the best feature of the reporting in Murex is the job recovery. If some of your report generation fail, from the job recovery you can re-run the report on the failed subset.
It might take many iterations but in the end you will end up with the failed trades. You can then exclude the failed trades or investigate them.

It can be used as a great tool to test if the EOD will run ok and zero on the trades that might cause issue.

Then of course, once you have your datamart running and all is good, what you need to build is the proper view/layout but that’s a different lesson.

What about you? Any good tip to share?

Tips

Exporting a browse screen – The best way

2 Comments

Murex has many browse screens: trade query, accounting journal, payment query, etc… And associated with these screens comes the question: how do I get that information outside Murex?

There are multiple ways of doing it but there is a first question to answer: what do you need it for?

Exporting a browse screen on a regular basis

If you indeed after a browse screen exported on a regular basis, a report is probably the better solution for you. You have multiple options:

  • Rebuilding the browse in a viewer and making a dynamic table on it (I would not recommend that solution expect if you have another use for the viewer).
  • Re-selecting the fields you need from a standard TRNRP_PL (or whichever appropriate) dynamic table. This is good if you’re after some calculated fields which are not always available in the browse directly (How many times did I get the request to have PL figures along with the trade query)
  • Building the report using a copy creation of the table your browse is based on. It might not work in every case but for trade query it does work fine. Just reselect the fields you need from the table and/or the related tables and you’re all set

Reports can be automated during EOD and produce data automatically.

Exporting a browse screen on an adhoc basis

This one is probably where I can help you most.

There are 2 main ways of doing it. The first one is to use the classic windows shortcuts: Ctrl-A (select All), Ctrl-C (Copy) and then Ctrl-v (Paste) into excel/word. Good old classic. Never disappoints and always work.

The classic way is great especially if you have a limited amount of data to copy. It gets trickier when you start to have multiple pages (usually more than 300 lines). More Murex proficient people will tell you to use Ctrl-Shift-C and voila, all columns copied regardless of the number of pages. While it does work, be very careful.
One evening, I was leaving a customer site a bit late and could see someone still at his desk. That person needed to export that data and used Ctrl-Shift-C and the pop up window Copying was still there. The problem of Ctrl-Shift-C is that it loads all the data from the server to your computer clipboard. If the amount of data is too large for your memory, the java process might run out of memory and while you believe something is still happening, it is in complete limbo. And you don’t want to waste your evening because of that!

So here’s the better solution when the amount of data is large: File-Export… The export data lets you export all data to a file (on your computer). You can choose to export all pages and it will do it by itself leaving you with a csv file in your client directory.

Somehow, while this function is much more reliable than Ctrl-Shift-C, it is quite unknown. Maybe because nowadays everyone copies/pastes everything!

Tips

Murex viewer – My 10 tips

Murex viewer, I still remember when it started being available in the very early production releases (2003 I think?). Concept seemed fantastic but it still needed to mature.

The concept is simple: rather than showing hardcoded/static screens to show results and/or to perform actions what about letting the users build their own and re-arrange them as wanted. The viewer was born with functions very similar to pivot tables. The source data being everything Murex static data and all computed data. Add filters, calculated fields, conditional formatting, linked views and you end up with a very rich environment.

Icing on the cake, Murex viewer comes with some preconfigured layouts simplifying everyone’s work as one only needs to modify as required. It is also a showcase of examples where one can see what can be done and how to try to harmonize the views together.

But with such a powerful tool, you won’t master it on day 1 (not on day 2 either). So let me give you 10 tips to become a pro with the viewer:

  1. Use the search function! The size of the data dictionary is staggering. Worse, sometimes fields appear multiple times and do not always display the same value (reason is usually that some fields are asset specifics). Ctrl-F and F3 are your friends. And remember that the search function works only one column of the data dictionary at the time
  2. Don’t over commit. Often I got calls from support teams unable to achieve what they wanted in the Murex viewer. Some functions and/or data might not always be available. Except if you’re 100% sure it works, don’t promise you will deliver it to the enduser
  3. GMPs are your friends when you need external data! This ones always come sooner or later when the traders want to access extra data/inputs. For instance, they wish to set a date limit for short dated bonds. This date could be entered through GMPs (rather than hardcoded). Best of all, when using simulation, the GMPs will be available in the loaded market data for easy access/input
  4. Viewer is not eTradepad! Typical example of being carried away, the viewer is a tool for displaying data and not a calculation engine. It is easy to be mistaken when opening the formula editor as it looks like the eTradepad formula editor but they are different!
  5. Be careful with your colors. This might sound obvious but actually I tend to find it the hardest part of the Murex viewer. When I was preparing demos, I usually ended up spending more time on the colors to use rather than on the data itself.
  6. Endusers should not be able to modify views. This is actually quite important. One would believe that giving everyone the right to create their own would alleviate the support team workload. Quite the contrary. The number of views will grow out of control and supporting users using different views is a nightmare.
  7. An extension to the point above: Try to limit the number of views in the system. As much as possible try to rationalize the views. For support it is much easier when the number of views is low. For upgrades, it is also less work.
  8. Try to limit the number of views on screen. Murex has a client-server infrastructure and most calculations are done one the server side. But the rendering of the screen is done on the client side. If you start to have many views with a large amount of data, you might end up with the ugly out of memory java error.
  9. Item formulas are great but don’t abuse. Items formula lets you use calculated fields as line breakdowns. I often ended up using them when I needed to aggregate 2 different breakdown fields.
  10. New functions. That’s the best part about the viewer. Each new Murex release comes with new features be it graphical or within the viewer, always inquire about the novelties are they’re usually great eye candy!

So here are my 10 tips about the Murex viewer. What about you dear reader? Any other ones?