If you’ve never heard of them, that’s probably for the best but they’re always worth discussing.
Most actions in the system that needs automation can be done through processing script (changing the date, running a report, checking DB results, etc…) or through the workflow or specific interface (importing trades, market data, etc…). But in some cases, you might need a function in the system to do something automatically and it is not automated at all.
It usually ends up in a meeting where people look for solution till someone mentions: XML Macros.
What are XML macros? XML macros allow to automate a certain path in the application as if someone was entering all the relevant information and clicking on the appropriate fields. Recording your macro generates an XML file that you can then load via a script (on paper sounds perfect for automation).
The extra bonuses of XML Macros are that you can modify the XML yourself (for instance, username/password groups or any other typed fields) very easily AND that they can open up a session up exactly at their very end. (For instance, choosing a portfolio and loading the simulation).
On paper, looks great and feels like a bulletproof solution. Unfortunately, I tend to run away when they’re mentioned for quite a few reasons:
– They each have their own JVM. So if you plan to use them to ease the user access into the system, the user machine might end up out of memory as each session will eat up 250-500 Mo (depends a bit as to what the user is doing)
– They’re completely dependent on path built: if the path changes for whatever reason (change of version, change of configuration), the macro will need to get rewritten to adapt to the new version
– If username/password changes, one needs to look into it as well and update them.
Automation is often a set and forget solution, but in the case of XML macros, at each change (and on a regular basis) they need to be checked as they might stop working.
If automation is absolutely required and XML macro is the only solution, you need to consider an extra check post the XML macro run to ensure that the job was done properly (usually a good old DB check processing script is perfect).
If you have stories or tips about using them, feel free to share below!
Hi
I’m from Mexico and I have a question about a difference between murex 2.11 vs. 3.1. Actually I need to create the same macros we use to work with in murex 2 in the new version but I cant find the command to show the black screen of cmd to visualize the execution of the code.
We find that the code to show the process on the murex screen is /MXJ_SCRIPT_GRAPHICAL:Y but I want to know the way to see the black screen.
Regards
Au
Hi Au and welcome!
The first thing I would check is to see if you still need XML macros. XML macros are a bit of a last resort thing when you cannot do something automatically in the application. Let me double check but I think we do run it with launchmxj.app but I can’t remember if it shows the steps on the screen on not. Will try today!
Just checked and indeed with launchmxj.app, it shows event 1, 2, 3…
My side relies alot on the XML macro to run simulation and export the results in a csv format text file onto local harddisk in Mx211. But now, while on hte migration to Mx3.1, we notice that XML macro no longer support export of simulation results from viewer. Any solution?
Yes, we do need XML macro. And Murex isnt entirely helpful by just stating “xml macro is a internal testing tool and not officially supported in MX3.” and wash their hand.
Hi, actually the best is to usually build a viewer in the simulation with all the data you need and then you can easily build a dynamic table on that viewer and export all results to DM (and dump to file if you want to).
If you have things like risk matrices, you can already put them in reports.
Hello,
unfortunately i am locked out of Unix access. Please advise how to:
1) run macro recording from the windows dos screen
2) record macros from the GUI
3) what changes I need to make to the .cmd file to allow macro recording and running
Hi, java commands can indeed be run from Windows or from Unix, as long as you have the right jvm that’s all that matters. So you can take the launchmxj.cmd script (along with mxg2000_settings.cmd) and use the syntax launchmxj.app -mxmacro /MXJ_SCRIPT_READ_FROM:MACRO.xml
To write a macro, you need to add to your client: /MXJ_SCRIPT_WRITE_TO:file.xml . You do what you want to automate with your client session (through the GUI) and then you exit the session. The file should generate then. You can also use UI Tools-scripts-stop script writer.
Cheers
Hi,
I am trying to export a TEXT file from my simulation viewer by using XML script.
I manage to run the “read” and “write” portion.
However, when i run my XML script that is recorded, the download text file portion of the script is not recorded.
–
After some digging and multiple phone call.
a friend gave me this to try, but i could not make it work:
I was told to insert this at the end of my script.
can you help me make some sense here?
thank you.
If you need to extract data from your simulation, I would probably recommend you to use a Simulation view based dynamic table and from there you can easily automate it in a processing script. Indeed, there is a bit more work than just a dump to text but it will be a lot more reliable. (and more resilient to upgrades)