/
Data flow

Data flow

In chart below you can see how your data flows when you use Scheduler Cloud app:

TTPSCSD665_v1-20260313-231134.png

 

Whenever you access any of the page of The Scheduler, the flow is the same:

  1. User opens one of “The Scheduler” app pages (for instance, “Scheduled issues” project page).

  1. Once opened, Jira begins to run AWS Lambda in order to render iframe in browser where content of our Forge app’s UI is displayed

  1. Once UI iframe is loaded, browser begins to load frontend scripts related to our app

  1. Once scripts are loaded, our app begins to fetch data necessary to display content of our app, which source may vary depends on which view user is currently opening  – for instance, when user opens “Scheduled issues” page, we fetch list of their Scheduled Issues from our remote backend via invokeRemote, but when user opens Create SI Wizard, we fetch list of available work item types from Jira Cloud REST API via requestJira.

All communication between user browser and Jira Cloud REST API / our app’s remote backend is securely handled by Atlassian – we do not use there any self-made extra authentication layers, like custom JWT tokens.

In both cases (requesting Jira Cloud REST API and our app’s remote backend) browser does not request endpoint directly – instead, it in fact calls one of Atlassian’s internal API’s, in which under-the-hood Atlassian opaque request with extra information (such as authentication token and account id of user who initialized request), send it to desired endpoint, receive response and send this response back to user.

When app’s UI send request to Jira Cloud REST API, request authentication is completely handled by Atlassian, but when request is send to our app’s remote backend, we as app vendor are responsible for authenticating this request as part of Forge Remote contract. However, instead of handling authentication logic manually, we’re using built-in authentication handling available in atlassian-connect-spring-boot (which is one of Atlassian’s official cloud app frameworks) via @ForgeRemote annotation (see Authenticating requests from Forge section in atlassian-connect-spring-boot README.md file) – that way we ensure that verifying incoming requests in the way Atlassian itself recommends to do so.

Regarding requests made during Scheduled Issue execution – in this situation there is no user context available, so we can’t use it to authenticate communication with Jira Cloud REST API. To deal with it we again follow approach recommended by Atlassian, which is based on hourly executed scheduled trigger. In this scenario, every hour our Forge function invokes one of our app’s endpoint via invokeRemote. Because @ForgeRemote annotation not only verify incoming request, but also – if such verification completed successfully – saves app system token to our database, we can use this token when running Scheduled Issue to communicate with Jira Cloud REST API.