SQL Tuning Services: Invoking Tuning Report with URL containing the JobID – alternative to randomly generated URL

We know how to work with the „JobResult“ API today. This gives us access to the original access pathes as long as the meta data and EXPLAIN data is available. But we consider the handling difficult - especially when communicating with developers. It requires some coding and interface to request the URL for a given jobID via REST call. Instead, we would consider it ideal if the URL is not randomly generated, but contains the jobID somehow.

Example of the process and details:

1. Developer has coded an app with inefficient SQL

2. The Db2 experts use the Tuning Services to explain and analyze. This results in EXPLAIN data, meta data, and a job ID

3. Results are being communicated via email to the developer, including the jobID

4. Next:

   1. Today, the developer needs to invoke JobResult to get a new URL if the original URL is no longer cached (this requires some coding / web interface, native REST call to today retrieve an URL like this https://<hostname>:9444/tuningservice/v1/ve/viewer/25533b5c-78be-43f6-a105-c3a0c4e7b908

   2. The idea is to instead use a randomly generated token to include the jobID in the URL like this: https://<hostname>:9444/tuningservice/v1/ve/viewjobid?jobid=1854831651022966784. This way, one could send this URL to the developer after their analysis, and the developer could immediately open the URL, without any REST call in between. If the report still is in the cache, it would be displayed immediately. If not, invoking the URL should kick off the rendering (given that the meta data and explain table content is still available) and then display the report.

5. The developer might look at the report immediately when reading the email, or after his vacation, or even later. Plus, our documentation / archiving use case is also fulfilled, as reports can be invoked any time, as long as the jobId is known and the data is not pruned.