Volker Eckardt's picture

Hello Community,

Thanks a lot for your continuous interest in this tutorial. There are still some sessions to go and it is my plan to cover also some non reporting requirements (like I have already done with the custom semantic checks).

In this tutorial I like to explain some common coding techniques to achieve specific goals, but also to strengthen your general JavaScript know how within ARIS:

  • Report full compliant with Business Publisher
  • Support for fixed file names for all output types
  • Section print – Only once
  • Section print – In case a name change is detected
  • One single function for attribute printing

Note: In addition I am going to reduce the code and layout complexity a bit by removing internal information (like the ID’s).


A) Full compliant with Business Publisher

If you deploy your report to the Business Publisher you will identify situations where your report will just not work (error "unsupported method in bp"). To solve that you need to identify which functions in your code are not Business Publisher compliant. Generally there are two techniques to find that out: Reduce your code step by step until it works. Then code the not working elements differently. Alternatively you can conduct the online help function-by-function to check which of the code elements are not allowed in Business Publisher (You may have seen the note: ‘This method is also available in Business Publisher Report.’).

In my case I have identified the function getSelectedObjOccs and the custom dialog itself as not compliant. A possible approach is now to add conditions when this code parts shouldn’t be executed.

We need a global variable to identify if the report will be called in Architect or Business Publisher environment.

To hide the unwanted function call we will add the following statement (our code has been already prepared in case the variable objoccs is empty, so we don’t have to do anything else.)

In the dialog function we use a similar technique. We add the following statement right on top to prevent this function from execution in Business Publisher mode.

By having both tasks completed, your report is now ready for publishing. For further details about the deployment please review my previous tutorial part 7.


B) Support for fixed file names for all output types

Since tutorial part 5 we are able to handle a common file name, but only for Excel. Because it is suggested to reduce the number of “program limitation” as best as possible, we will enhance the code to allow a fixed file name for all output types.

First we define two global arrays in our script “Common Reporting Functions.js”. These arrays contain all possible file formats and the corresponding file extension:

Additionally we add a new common function to retrieve a complete output file name.

This function will be called in our main() function.

Finally we remove the Excel note from our dialog field.

From now on you can choose this option for whatever file type you execute the report.


C) Section Print – Only once

This is a common requirement and therefore I like to explain the general implementation procedure here. Initially the database information is printed multiple times. To hide all duplicated output we have to do the following:

Add another global variable. It is set to “true” per default, but will become “false” after the first print.

To prevent further output add now the following if statements around your code (1). Additionally define a criteria when the variable should become false. In this case here it is when any output type is requested except Excel (2). (You may have a different condition, this is just an example. For sure you do not have to add a condition here.)

You see immediately in your PDF or HTML output that the DB Information will be printed only once.


D) Section Print – In case a name change is detected

This technique is similar to the C) option, but the data will come back in case a name change is detected. In my example I like to print the model name and path only if it is the first page or the content is different to the previous.

We use again a global variable, to hold here a string rather than a boolean. We will initialize this string with something to make sure that the comparison will detect a difference.

The code to ‘disable’ we cover again with an if statement (1) and set the global variable to the current model path and title (2).

This way the section with the model information will come up only on the first page and in case another model is detected.


E) One single function for attribute printing

The value of this step might be under discussion. It’s a kind of achieving high code reusable and keeping the code simple. But because my generic function writeAttributes is double as long as the initial code the general value is limited (in terms of code readability and clearness).

But nevertheless I have done it and the result looks like this (You see two more if statements to react on the given parameters.):

The main program can then stripped down like this:

Concerning the parameter ordering: the general advise is to start with global values (oOutput), continue with session specific (currFilter) and complete with call individual (objDef, Maintained –yes/no). But this is rather a coding convention in your project.

I leave it up to you to adapt this step.



Use these techniques to allow a dynamic program reaction on different calling or data situations. It is suggested to support Business Publisher (see solution A) and it might be requested to support also as many as possible output types (see solution B). Review the output and hide as much as possible redundant information (see section C and D).


Please download the final report file from here.

Next Article

In the next article we will utilize the discussed techniques to create a new matrix report with similar content.

Related Articles

Any kind of feedback is very welcome!

Best regards, Volker