nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Two separate API endpoints for process instances

onkovic

The Alfresco Process Services REST API, as well as the Activiti the REST API, differentiate between historic process instances and process instances. Can somebody explain why this distinction is made since they both refer to the same object?

The thing I don't get is, why there even are two separate API endpoints. I feel like it would be easier to set a boolean property like "hasEnded" for every process instance and only use a single API endpoint for process instances.

But maybe I'm not getting something completely obvious here and it has something to do with performance, certain restrictions or something else. Could anybody help me understand this?

Thank you in advance!

Find more posts tagged with

Alfresco Process Services

Comments

bassam_al-saror

Process instances live only for the lifetime of a process and will be deleted as soon as they are finished. Historic process instances are always available whether finished or not. The reason for that is performance engine execution is faster when it only deals with in-flight processes compared to have to work with historic processes (which could be millions).

If you are looking to query for in-flight process it's faster to got for the process instance endpoint. Historic process instance endpoint will be slower depending on the amount of historic data.

paul_roth

Hi Zlatko, by noting performance you are on to an important area of consideration. If you look at what we have done in Activiti 7, which will become the core of APS 2.x going forward, we have taken this to an entirely new level aimed at best practices for Cloud native microservices architecture with excellent performance and scalability, where the Query Service is broken out into a highly optimized operational subsystem.

mdtabrezmca

Hi Bassam,

It is good to seperate live process instances and historic porcess instances. But one point to take out from this is live process instances are also stored in the db and not in the in any cache so performance purely depends on db.My concern is i have an issue with editing the closed process instances if some how i will keep process instances live then for how many number of live process instances the system will break.

bassam_al-saror

In flight processes and historical process instances are stored in the database but in two different tables. By time in flight processes table becomes just a fraction of whats stored in the historical table since in flight processes are deleted once they are completed from in flight processes table.