Request page automation in NAV 2015

  • Post category:NAV 2015
  • Post comments:13 Comments
  • Reading time:9 mins read

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.


This function lets you run a request page for a report, without actually running the report. When the user clicks OK, the function imagesimply 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.


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.


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.


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?


Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 13 Comments

  1. ajkauffmann

    I assume that the main reason for the XML parameter is because of the report scheduling functionality. Most probably the current implementation fulfills the needs for this functionality, so they didn’t design a complete solution that can be used in a more generic way.

    1. Vjeko

      Yes, very likely so – but still, a serializable XML class would still allow them to save and read to and from XML, plus it would allow us to handle data in a strongly-typed manner.

    1. Vjeko

      Obviously not – I’ve missed that one. Thanks, Natalie!

  2. Rafael Rezende


    The SAVEASHTML function is there since the classic days. Unfortunatelly it’s ‘obsolete’ and just gives an error message 🙁


    1. Vjeko

      Rafael – thanks for pointing this out. I must admit – I was too lazy to even try if it now works. My bad 🙁

  3. Mirko

    Errors explanation:
    “invalid path” because the report couldn’t have been saved because if the report errors out, no pdf is created.
    if you instead use the “void version” of the function, the program stops right at your hardcoded error.

  4. Simon

    Setting the option variables through the xmlparameter with the EXECUTE function seems not to work. One example is Report 11511.
    Can you confirm this?

    1. Simon

      to be more specific… Setting Record variables with the xmlparameters dont work.

    2. Vjeko

      Well, I don’t know – you are probably right here. I didn’t try, and I can’t spend time to try it right now.

      1. Simon

        The Problem was that, the OnOpenPage Trigger for the RequestPage gets triggered even though the page will not be shown in the EXECUTE method.
        Furthermore the Trigger is executed AFTER the Xmlparameter are parsed… because of this my Parameters got overwritten with the Default values from the OnOpenPage Trigger.

        => My assumption in the previos post was wrong… it is working. But i dont know if it is intended to execute the Trigger in this case. for me it is a weird behavior.

Leave a Reply