Subreport - trying to call and run from main report

[dqueubed]

@bjrmatos ... looks like I'm running 3.9 locally and should probably update. That said, it does not run for me in the playground. I'm assuming the playground is 3.11 as well?

[bjrmatos]

@dqueubed to be clear we have not landed the fix yet, we have it but it is not published.

yes, the playground is on 3.11 now but still does not contain the fix, the video I am showing is to demonstrate how it works on 3.11 locally (without any fix applied).

[dqueubed]

@bjrmatos ... aaahhhh, ok gotcha. I guess that also explains why I can't seem to update my local version to 3.11 - tried a few times using online instrux but when I fire up JSReport is still says I'm on 3.9 <thumbs_up>. Also, in the video when you changed the recipe to HTML and the sub report ran only showing the text "Amin" ... I am indeed seeing THAT as well. Not rendering the results, but only showing the Amin response.

q: what do you need me to do here?

Happy to provide details, test, or ???? ... just let me know. As always, thanks so much ... very appreciative of your time and assistance. :-)

[bjrmatos]

but for now, I'd like to just get my secondary/sub report to render

I focused on the issue that you were not able to render the subreport, I thought, that was your main problem so far, that you were just trying to make the render happens without any data (for the testing), but now that it is clear that the render happens let's focus on the next.

Also, in the video when you changed the recipe to HTML and the sub report ran only showing the text "Amin" ... I am indeed seeing THAT as well. Not rendering the results, but only showing the Amin response.

yes, it only shows the text "Amin", but that makes sense because you are not passing more data in your code. (as mentioned I thought you were just trying to make the render happen first so i did not give you more advice about how to make the data available to the subreport)

jsreport.render({
                    template: {
                        name: 'msub_rptSub'
                    },
                    data: {
                        name: 'msub_sub',
                        detailID: 'detail id data goes here'
                    }
                })

here you have and example of what you can do to pass the sub data, it is one of the many things you can, in this example, I am doing it by loading from the data entity you have available there.

I think this gives you the general idea, you can tweak or change it depending on your needs. please remember that although the example is available on playground, it is not expected to work there right now (until we land the fix), so try it locally.

[bjrmatos]

also, pay attention to this part when trying it locally and put that jsreport.serverUrl in a comment

[dqueubed]

Thanks @bjrmatos ... trying this now.

[dqueubed]

@bjrmatos ... ok, here are my 2 reports running locally in their entirety. From my main report (msub_rptMain) you can see I have the detail function coded with the template and datasource. Running msub_rptMain yields this ...

The subreport (msub_rptSub) looks like this when it's been run as a standalone, using msub_sub for a dataset.

However, clicking the "drill down" button from the main report doesn't actually run the report ... it simply yields the Amin string I have set to let me know if I'm (programmatically) in the right location.

I should be seeing the entire report being generated, right?

[bjrmatos]

I should be seeing the entire report being generated, right?

yes, if you apply the changes I made in the example, you should see the sub report rendering as you would expect

testing subreport.mp4

[dqueubed]

@bjrmatos ... <DOH>
Man ... I apologize. I didn't fully understand that you'd made adjustments in the playground :-( Anyway, indeed, I was able to copy and run the changes successfully.

qq: is this how I need to do it moving forward? Or is there a patch/fix/alternative way I should look to do this going forward?

I know there are more people to support than just myself, and I genuinely appreciate you taking all this time with me. It's very much appreciated.

Thanks again, and let me know.

[bjrmatos]

qq: is this how I need to do it moving forward? Or is there a patch/fix/alternative way I should look to do this going forward?

well, it depends, I am just showing how to pass the data to the subreport the easy way, based on your data entities, however, this does not mean that it is the approach you should take in production. after all the data entities are used more for testing, because on production you will feed the report with your own data (which is likely to be dynamic and not static like the data entity).

the main question here will be how you will get the data for the subreport, in the example i shared i get it from your data entity, but that is just for testing, in real world you can do either of the following:

• fetch the data for the subreport before you call the render of the subreport, this way you do http request (from the browser) and communicate with your server to get the needed data

or

• when calling the render of the subreport pass an id, your subreport should have a script attached that takes such id from data and uses it to execute an http request to your server (at the beforeRender step), then in the script you use the results to populate the report data req.data = <http request results here>

what you choose depends on what looks easier for you, and also if the communication with your server is already secure from the browser, if not then the solution with the script looks better because you can hide the http credentials that your server probably needs to authenticate and return correct response.

[dqueubed]

@bjrmatos ... great food for thought. We do indeed feed data to our reports dynamically and render from a script, but I'm always curious about options and other opportunities, so I may mess around with the browser-based method as well. In all instances, I am most appreciative of your help here. Thanks as always for your support ... you guys are awesome.