Update Your Financial Integrations

One of the biggest challenges in the migration process is to adapt your integrations to and/or from external financial applications. While the process of communicating with the Tempo Account REST endpoints centers on switching the url, the situation is complete different for syncing worklogs. In Tempo for Jira Server/Data Center most companies leverage the Tempo worklog servlet for that purpose. However, this endpoint (or at least a similar endpoint) does not exist for Tempo for Jira Cloud.

In Tempo for Jira Server/Data Center, the worklog servlet returns detailed information not only about the worklog but also about the user (Jira user properties), the Jira issue that the work has been been logged against, the Tempo Account which the worklog belongs to and the approval status of the worklog itself.

If you need this additional data in Tempo for Jira Cloud you will need to use several REST API endpoints to achieve the same result. On top of all this the Tempo REST APIs for Jira Cloud are paginated which will also force you to handle paginated responses.

With all this in mind, you will need to redesign your implementation flow between Tempo and your external financial tools.

User properties

The user properties are kept in Jira. To retrieve this information you will need to leverage the corresponding Jira Cloud REST APIs.

Tempo account information associated with a worklog

The Tempo worklog REST API only returns information about the worklog. Since the Tempo Account can be set either against the worklog itself or on the Jira issue level where the worklog is tracked, you might not get the Account information for the worklog itself from the worklog REST endpoint. To retrieve this information you will need to use /worklogs/account/{accountKey}.

Worklog approval status

The worklog approval status is not stored against the worklog itself. A worklog is only considered as approved when the worklog's user's timesheet has been approved for a time period that includes the worklog's date (not creation date though). To retrieve this information you will need to use /timesheets-approvals/user/{accountId} .

Follow Best Practices

Keeping all of the information above in mind, you might wonder what’s the best way to achieve what you have done before in a single call? Depending on the amount of Tempo Accounts and users you have you will need to make a lot of API calls. There are basically two main approaches available. In the end you will need to decide which way you choose to move forward. And it also depends on what level of information you need for your financial integration.

Regardless of the approach you take, you should try to retrieve as few chunks of data as possible.

Use a datalake

A datalake can act as a middleman between Tempo and your financial application. The datalake collects all worklogs, all Timesheet approvals and all Tempo Account worklogs. Then you can map the worklogs against the approved timesheets and the Tempo Accounts to gather the information from the Tempo Account the worklog is assigned to.

This approach may be appropriate when you already have a datalake infrastructure in place and you want to see the collected data for other purposes (e.g. reporting).

Gather additional data on the fly

Another approach is to get the additional data on the fly. To do so, you make additional calls to the Jira and / or Tempo REST endpoints for each single worklog you retrieved in your original REST API call.

1. To get the approval status of a worklog you call the worklog approval endpoint where you populate the from and to parameters with the returned date field from the response

2. To get the Tempo Account you will need to check against the Jira issue API and retrieve the information for the Tempo Account custom field. More detailed information can be found in the REST API section. Since the Account can also be set on the worklog level, you will need to introduce the same logic as Tempo uses behind the scenes.

   • When Account is set on the worklog level, use this Account (no need to call the Jira REST API in this case),

   • Then check the Account which is set on Jira issue level.

   If the approaches listed above do not return any account information, then there is simply no Account set against the worklog and you will set a NULL value.

Since this approach requires a lot of back and forth calls, it may take a while to complete and iterate through all worklogs.