Blog

Most of What’s New information about NAV 2015 will mostly talk about the Word report layouts, as well as the C/AL support for these. However, most of the What’s New documentation doesn’t have a single word about what I find among the most exciting new reporting features in C/AL: the capability to programmatically control the request pages.

A couple of days ago, while digging through the C/AL in search of new undocumented features, I’ve noticed the following:

Quite an offer, if you compare it to the NAV 2013 R2 carte du jour:

It was less than two weeks since I delivered my first What’s New in NAV 2015, where I talked about the new reporting functions as well, but I didn’t remember having seen any of these documented anywhere, let alone talking about them. These four were conspicuously absent from the documentation: RUNREQUESTPAGE, EXECUTE, PRINT, SAVEAS. I’ve had to re-check the RTM help files, where in fact I saw them briefly listed, with exactly one sentence about each of those. I think they deserve much more introduction.

So, let’s take a closer look at each of them.

RUNREQUESTPAGE

This function lets you run a request page for a report, without actually running the report. When the user clicks OK, the function simply returns a text value, which is an XML document describing the user’s selection and filters of the request page.

For example, this line of C/AL code…

…shows the following request page, and if you set these options and click OK…

… you get the following XML document as a result:

Nice. Now, what is this XML document good for? Many things. For starters, to feed the next three functions.

EXECUTE

This function runs a report without showing a request page. It receives the parameters as an argument of type text, and you can feed the results of the RUNREQUESTPAGE to it. If the report you are executing is a processing-only report, then it will simply silently execute. If it’s a printable report, then it runs in the preview mode.

A great addition to the C/AL stack, however, I wonder, when they were already at adding this new function, why wouldn’t they allow this:

Yeah, you guessed it right: it is a void-type function, does not return a value, and unfortunately you cannot capture whether it ran successfully or it failed. If it fails, it fails. If you want to catch it, you need to wrap it in a codeunit. A pity, but still, a great addition.

PRINT

The same as execute, only it prints the report to the specified printer. It doesn’t show any request page, just prints the stuff out. And yes, it suffers from the same limitation: it does not return a value, instead it either silently succeeds or goes down with fanfare.

SAVEAS

And finally, the mother of all SAVEAS… C/AL functions – the, well, SAVEAS function. It does the same as SAVEASXML, SAVEASPDF,  SAVEASEXCEL, and SAVEASWORD, only it does it without showing the request page.

Funny thing with this function is that there are two funny things with this function, which is in fact three of them. First, for some reason, it allows you to capture the boolean result indicating whether it succeeded or not, unlike the other two functions. Why this is so, beats me, but this most certainly compiles:

And it most certainly runs, too:

However, when I introduce a deliberate error, just to see what kinds of things this boolean return value can sustain…

… it fails in a most peculiar way:

So yes, it does capture the error, but gods know where this one comes from. So that’s the second funny thing. Funny thing is that there are not three funny things, but four funny things actually, because when I uglify this code like this…

… and then run it, I don’t get that nonsense “value cannot be null” error, but I actually do get what I expect:

And last, but not least, the fourth funny thing about this function is that, for whatever reason, it cannot save as HTML. There is a new reporting function in NAV 2015, as well, called SAVEASHTML, which allows you to save any report as HTML, but the REPORTFORMAT built-in type supports only these options:

Looking at these peculiarities with these four functions, I would say that they were rushed into the RTM, and I would hope to see these issues fixed in a hotfix, cumulative update, or an R2 (if there will be one).

What are the possibilities

Well, they are aplenty. For example, you can now fully automate the execution of batch jobs which required options to run properly (for example, the Adjust Exch. Rates that I’ve used as an example here). Like, for example, saving the results of the request page in a BLOB field in a table, and then reading it from there when the report needs to be executed.

Also, writing a .NET class that makes it easy to access the request page through an object model, and then serializes its results as XML, should be no big deal.

Now that I am at serializatino, I truly wonder why nobody at Microsoft didn’t think of that. Why, instead of handling the request page parameters as text representing XML, couldn’t Microsoft provide a serializable .NET class that allows us to fully programmatically automate request pages.

In any case, even with the funny behavior and no real object-model support, these four functions are a great addition to C/AL stack and I’ll definitely use them and abuse them to world’s end in my projects.

What’s your thoughts on them?