From SAP BPM Product Support we got an interesting perspective of the hottest questions customers use to have. One of them comes up when they receive an error message like this one:
******************************************************************************************************************************************************************************
Caused by: java.lang.RuntimeException: BPMN process could not be started; maximum number of 1000 allowed active processes reached; try again later
at com.sap.glx.process.adapter.bpmn.impl.ProcessInstanceCountBrake.assertNotInErrorState(ProcessInstanceCountBrake.java:128)
at com.sap.glx.process.adapter.bpmn.impl.ProcessInstanceCountBrake.assertProcessStartAllowed(ProcessInstanceCountBrake.java:118)
at com.sap.glx.process.adapter.bpmn.impl.BPMNDisasterBrakes.assertProcessStartAllowed(BPMNDisasterBrakes.java:50)
at com.sap.glx.process.adapter.bpmn.impl.BPMNInstanceHandler.onConstruction(BPMNInstanceHandler.java:129)
at com.sap.glx.core.dock.impl.DockObjectImpl.creation(DockObjectImpl.java:284)
at com.sap.glx.core.dock.impl.GalaxyClassImpl.create(GalaxyClassImpl.java:224)
... 59 more
******************************************************************************************************************************************************************************
They understand that the root cause is because the system reached the maximum threashold of active process but they do not know why.
ℹ See KBA - 1869499 - Token count exceeded in Process <...> The number of tokens in the process reached the maximum allowed token count ...
In the KBA 1869499 you can read "you can increase the setting if such many tokens per instance are desired" but you do not know which is the limit that we can increase this setting because indeed you do not understand when a BPM process instance is in memory and is here when the main question comes up:
"Which are the values I have to set for memory threadshold?”
To try to clarify this idea I wrote this small blog based on a system with one instance and one server node but please bear in mind that the mechanism is much complicated than what I explain here.
In our system example we go to BPM System Overview Process and Tasks – We see that there 66 process instances which are in both in Final and not final status but not archived:
In the Process instance Memory threshold - We see that there are 66 process instances. The same number than in BPM System Overview Process:
In Open SQL Data Browser for table GLX_C_SEPARATIONS we can see following entries. ALL of them in INA status:
This status can be INA, ACT, ERR, WEA.
If we have a look at the Manage Process instances, we will see 3 main processes and 1 subprocess. The subprocess is e5d5eb2f661a11e2c2410000008bf1fa
which is not listed in table GLX_C_SEPARATIONS but counted as process “In progress”.
So now the question is from where is coming the other two processes instances which are Main process instances and listed in table GLX_C_SEPARATIONS?
They are coming from the SUSPENDED instances:
Although JUST the ERROR STATUS = OK is mentioned in BPM system Overview – Suspended even though just one was listed in the SUSPENDED list in BPM system overview. This is because one is in ERROR status = ERROR.
http://help.sap.com/saphelp_nw73ehp1/helpdata/en/ba/9e2972c96340b39326393e21414926/frameset.htm
There are several points we need to take into account from a general perspective to set them:
1. Available physical Memory.
2. Number of nodes.
3. Number of users.
4. All the BPM information I wrote before related with BPM process models, their instances and their complexity.
Regarding points 1 and 2 our recommendation is to do it with the Quick Sizing tool:
You will find it here:
and here check the Quick Sizing tool.
Regarding point 3 and 4 this has to be done once you have understood which is your scenario.
In the previous "Sizing SAP NetWeaver Process Orchestration" document you can read the key points:
1.4.3 “Number of active process instances (consumes memory and execution threads)
A process which is currently running (such as executing a human task or an automated activity) consumes Java Virtual Machine (JVM) heap memory and one or more execution threads. The amount of memory and execution threads available must be sufficient for the expected concurrency. The amount of memory consumed per session is primarily related to the size of the process context .”
1.4.4
"...The standard sizing considers average context object size of 10 KB and basic flat structures , Deep data object structures which require complex mappings should be avoided."
1.4.7
"Process context data objects should contain only the minimum data necessary for the process flow. Writing to the objects should be carefully managed to avoid potential deadlocks such as might occur if two parallel branches of a process were to write to an object at the same time. Sizing is based on up to 50 data elements in a context object with a flat data structure. "
ð This are general sizing tips but it based on it, you need to analyse your process models and number of instances per each one. This has to be done by each case and BPM process model.
e.g. How many Data objects are created in a BPM process model?
How complex are the data types of that Dos?
How many loops do exist in the BPM process model?
How many sub process are associated with that BPM process model?
How many process instances are created of each one?
How many potential owners are set to each human task?
….
Each of them has to be repeated per BPM process model….
As you can see on previous points, these values affect the memory threadshold.
Hope this could be usefull for you. :wink:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
36 | |
25 | |
17 | |
13 | |
8 | |
7 | |
7 | |
6 | |
6 | |
6 |