Things are pretty quiet at work at the moment. 18^th of December sees the processing plant shutdown and then I start the clean up of machines and potential migration of our servers to a common platform and outsource the lot (from an IT perspective pretty exciting but pretty sad also).

This means that people are in wind-down mode, and it means that I am stuck with idle time whilst I wait for answers, pricing and decisions.

So dear reader, does that mean? Do I stare forlornly at the wall, do I work on my tan in front of the bank of monitors? No, it means I get in to trouble by looking for things that perhaps we really shouldn’t look for. I delve in to the deep and dark secrets…ok…ok…you get the idea… 🙂

Back in the old days (Smart Office 9.x I believe), we used to have a file called canvas.xml which we could copy to our users to easily give them a copy of someone elses shortcuts.

I believe that with Smart Office 10.x the Canvas.xml got sucked in to a super secret (only because I don’t specifically know where ;-)) location.

Now with 10.0.5.2 we were given a tool called “Mango Admin Tool” which allows us to export a variety of settings, including the elusive Canvas.xml – we can see this if we open the exported MangoData.zip and delve in to the Roamed directory and then one of our users who has saved a shortcut on to their desktop.

So, I wondered, what has been done? Now the kicker here is that the MangoAdminTool can be launched from anywhere, however after some inspection it turns out that pretty much all of the processing is occurring on the Smart Office server (the MangoData.zip gets saved to the ISO server) – so sniffing traffic from say my computer is largely a waste of time.

As it happens, I have a nice wee test lab set up where I can chuck Wireshark on to the Smart Office server without concern and capture some packets.

I will warn you, I flick between my test lab and my work DEVE environment, basically packet captures are done on my home lab, everything else in my work DEVE environment – there are differences which I try to point out as I embark of this little trek of discovery.

I created a shortcut called MForms on the canvas of the user m3srvadm. This shortcut executes mforms://jscript.

I installed Wireshark (and Fiddler – though that was a bit of a bust) and then ran the MangoAdminTool from another machine and captured what happens.

I did this and after some experimentation I managed to find the stream that had what I was looking for (btw: if you are new to Wireshark, there is a handy function which allows you to follow a TCP stream – so you get the entire conversation decoded in a single place).

Figure 1 – my MForms shortcut which runs jscript – yes, I know, I should have called it jscript or something intuitive 🙂

Now this conversation is between 10.255.255.72 and 10.255.255.70 – my test labs M3ISO10 (Smart Office server) and M3BE10 (the Business Engine) – so I think that there is a good chance that the Canvas.xml is stored somewhere on the BE.

Now, taking a look at my work environment things are a little bit different, but I have some ideas about what is happening. In my work environment my BE is WLMX02 @ 192.168.1.16, my Smart Office Server WLSO02 @ 192.168.1.17 – I am swapping to that as it is a little easier to work with and I am not doing anything as invasive as installing packet sniffing tools.

As it happens, I had previously done some exploring in LCM – if we go to our MangoServer (10.1.x or LSO 10.0.x), right click and select Lawson Grid -> Application -> Monitor Application and the click on the Web Components we get to see our Context Roots – the first entry – mangows has a couple of links

So with a name link mangows – it can only mean one thing to me…web services…so I clicked on the link….

Hmmm…some interesting stuff…a quick load of these webservices in to SoapUI and we can take a look at the different methods available to abuse…err…explore…

Now, looking at my packet trace, it looks like we are very ‘file’ centric – we see a reference to Canvas.xml and ‘Roamed Files’. As it turns out under the MangoSettingsManager webservice we have some interesting methods which imply file access

You’ll note that I have expanded out the GetFile method

If I open that up then I have a method which takes two entries – a FileName and at UserName

A quick check of my packet trace and I can see a filename and a username – coincidence, I think not 🙂

So I plug these in to SoapUI – don’t forget that you need to specify the authentication in the http header (so click on the Aut button and key in a valid username and password).

And I execute the method and I get a response :-O

A long encoded string. My experience with emails leaves me to think the string is a base64 encoded string, so off to a base64 decode website and I plug the string in decode and whala! Canvas shortcut goodness!

But that still doesn’t help us, gee, we can get the values and we can probably push values back in to the database, but we don’t know where it is – we suspect it is on the business engine…but…

So…last weekend I decided I wanted to know a bit more about the H2 database, and GDBC.

If you go in to LCM, in to a GRID environment, right click on the GDBC -> Lawson Grid -> Application -> Manage Application we get to the “Grid DB Broker”, this has a handy link called “View application configuration”

Clicking on this provides all sorts of possibilities

Out of curiousity I looked in to each of these databases and only came across information in the MangoServer. But then, I didn’t really know what I was looking for…now I do.

So if I click on the “H2 Web Console” under the MangoServer I see this

Instantly the “RoamedFiles” piques my interest (remember the packet trace referenced Roamed Files)

Expand it out and we can see “FILENAME” and “USERNAME” as columns in the table – now I issue

select * from ROAMEDFILES where FILENAME = ‘Canvas.xml’ and USERNAME=’scott’

And I get this

Gut feel is that the content isn’t encoded as Base64, it looks a lot more like hex codes for ASCII (how sad is that? :-)) – so off to a Hex to ASCII converter and I plug the content in to it and convert and what do you know…success!

The eagle eyed of you may have noticed in the LCM screenshot of the H2 WebConsole there was a path…

The IP Address is my Smart Office server and if I look at the path on that server I see

Our file…

Just how kewl is that?

So…again, what does this mean? Well, you can hose your settings quite happily if you choose to manipulate the data directly (though I would recommend fdisk as a better method to bring your environment to a scretching halt), you could probably even call the webservice and hose things that way. You could probably copy the MangoServer.h2.db from one environment to another and hose the environment that way too. In short, it’s not something that I’d recommend manipulating…ever…

By the looks of it, the Canvas.xml was effectively streamed in to the database, I’d expect that as Smart Office and the GDBC gets more development attention that the Canvas.xml file and all those other settings files will get broken down in to a table of settings rather than a streamed file.

You’ll also notice that there is a LSO.h2.db in the file listing – this is from the 10.0.5.x Smart Office install.

What this does highlight however is that I have some differences in the installation between my test lab at home and my environment at work – such as the GDBC at home is installed on the BE and the database is on the BE. There will no doubt be some performance differences between the two systems – is the GDBC better to be installed on the Smart Office server (which I actually thought I had done but…) – gut feel would be yes, but I have absolutely no data to back that up 🙂

Practical uses? Well, you can always troubleshoot issues with canvas icons not appearing in more detail – check the modified data of the database, and even interrogate the database to find what when there was last a modification and what the results are.

For me…I was curious and it’s another piece to the M3 puzzle 🙂