cancel
Showing results for 
Search instead for 
Did you mean: 

changeDeploymentTenantId does not set Tenant in Historic Tables

jorell
Champ in-the-making
Champ in-the-making
I couldn't find any info on this despite searching, apologies if this has already been addressed.

changeDeploymentTenantId in RepositoryService doent set tenant in any of the history tables which have Tenant_id_ columns (PROCINST, ACTINST). This seems like an oversight since the database ends up in an inconsistent state. Can anyone confirm?
5 REPLIES 5

martin_grofcik
Confirmed Champ
Confirmed Champ
Hi Jorell,

May be I do not understand the problem, but does it make sense to change the history?
When you have changed tenantId, is proper tenant id logged into history tables?

Regards
Martin

jorell
Champ in-the-making
Champ in-the-making
>May be I do not understand the problem, but does it make sense to change the history?
It does make sense if you are saying that deployment 'A' now has tenant 'T'. All the runtime process instances of 'A' will now have tenant 'T' but all the history tables will show blank tenant. So now, for reporting, if users of 'T' want to pull up reports on their processes, they will have lost all processes finished before the change in tenant. You will have process instances in the history table belonging to the same process definition but some will have tenant 'T' while others won't.
From my perspective a tenant is (should?) be basically an attribute of the deployment, the api also suggests this (changeDeploymentTenantId). So the historic tables have a relationship with a deployment through proc_def_id_ anyway. Having different tenant values for the same proc def values seems inconsistent to me but maybe I am misunderstanding the reasoning for this.

>When you have changed tenantId, is proper tenant id logged into history tables?
I haven't tested this out, I assumed it works but I'll test it out and report back here.

trademak
Star Contributor
Star Contributor
The history tables are not updated automatically. So you need to write a custom update script to make sure the history tables are also updated.

Best regards,

jorell
Champ in-the-making
Champ in-the-making
Yes I've written the script. I was more interested in the reasoning of excluding the history tables from the API.

trademak
Star Contributor
Star Contributor
Changing a tenant id is not a common step to make, because a tenant identifier typically stays the same. But of course there are cases where you would like to change the tenant id, and we support it in our runtime tables. But also changing all historic data might not be valid for all use cases where the tenant id changes. We could however add conditional logic that allows a user to define if all historic data should be changed as well. Could you create a JIRA issue for this?

Best regards,
Getting started

Tags


Find what you came for

We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.