BPT: Is there a limit for how many Active Instances a process can have?

BPT: Is there a limit for how many Active Instances a process can have?

  

Hi,

I´ve searched BPT documentation about this question but wasn't able to find an answer.

If there's a limit, can it be set on the platform (ex: configuration tool) or it depends on the infrastructure (ex: database space)?

Cheers,

João


I don't think there's a hard-set maximum, but database size, processor capacity etc. is of course a limiting factor.

Yes, it is a good question. Suppose the last process launch is fail because of the lack of resource, so this negative case should be in mind when designing a BPT.  To work around this, is it good to just limit the number of active process instances, say it 100, and then launch another 100 when the first 100 bulk have terminated?

Hi Putu,

You should think of 1000s to 10,000s, not 100s processes before you get into trouble with performance. It also depends of course what you're doing with each process. If each process uses a heavy query that takes 20s to complete, that'll be a problem, but if it goes to the next step in 1s, there's substantial less of a problem.

Also, BPT is typically used in situations where you do not control the number of processes, since BPT processes can be (and typically are) created automatically, e.g. triggered by incoming data via a REST service, employees filing things, etc. In those cases you don't "launch" 100 processes, processes are launched as needed. It's more about thinking what you want to do in a process and why, as opposed to batch processing. Use BPT when it makes sense, use something else otherwise!

@Putu, a process will not fail to launch. BPT was made in such a way that it is nearly impossible to fail. You could throw 20 000 new processes at it in a matter of seconds, and all of them will be handled correctly. (I know this from experience)

There's no way to limit the maximum amount of processes. Why would you? This would go against the very concept of BPT. It is designed specifically to be robust and to make sure that every instance is started and completed. 

Some things to keep in mind: 

Automatic activities have a timeout of 5 minutes. 

BPT is very much a "fire-and-forget" mechanism. You have no idea of when it will be executed/finished.

Hi Killian and Tim,

Thank you for quick responses. Now i am in a banking project for loan business that heavily uses the BPT. I have some issues:

1. The project has projection to attract about 1 million customers. 

2. Each loan application has 1-to-1 relation to a process instance.

3. A process instance will have about 10 automatic activities that calls end point service (rest or soap) and 3 human activities.

4. We use mysql and external entities for that BPT. 

5. A server is used for many applications in the bank, not only this loan.

My questions are:

1.  Is it safe to just "fire and forget"? The client challenge for that per , say it 100,  basis considering peformance issues those could be exposed by lack of resources.

2. The external entity is still in mysterious, what are the  limitations - functional, features, etc -other than the external entity"s action cannot be used to trigger implicitly?

3. Is it correct that many internal outsystems tables have no primary key such that cannot be clustered?

4. What best practise should be used for that use case?

Best regards and thank you in advance.

Putu

1. Yes, that's safe. The system by default is limited to 10 concurrent BPT threads (1 per Activity being processed) per SERVER so it will not hurt performance. If you need high performance, you need to use the new "lightweight processes" that have been discussed but I am not sure if they are public yet.

2. The big thing with external entities is that you cannot combine them with internal entities in the same query (they are different DB connections). Other than that, and no BPT trigger, they mostly work like internal entities. Instead of depending on the BPT triggering, you should wrap all CRUD with an Action *anyways*, and you can use that wrapper to trigger the BPT.

3. This is correct. Stuff like the logs do not have primary keys.

4. Depends on what you really mean?

J.Ja

Putu wrote:

Hi Killian and Tim,

Thank you for quick responses. Now i am in a banking project for loan business that heavily uses the BPT. I have some issues:

1. The project has projection to attract about 1 million customers. 

2. Each loan application has 1-to-1 relation to a process instance.

3. A process instance will have about 10 automatic activities that calls end point service (rest or soap) and 3 human activities.

4. We use mysql and external entities for that BPT. 

5. A server is used for many applications in the bank, not only this loan.

My questions are:

1.  Is it safe to just "fire and forget"? The client challenge for that per , say it 100,  basis considering peformance issues those could be exposed by lack of resources.

2. The external entity is still in mysterious, what are the  limitations - functional, features, etc -other than the external entity"s action cannot be used to trigger implicitly?

3. Is it correct that many internal outsystems tables have no primary key such that cannot be clustered?

4. What best practise should be used for that use case?

Best regards and thank you in advance.

Putu

I would add one more question to this list. What is the best way to filter and reject a duplicate BPT call? When I say duplicate, it can be based on SSN or whatever user defined criteria.


Hi Goldy Lukka,

I'd say those criteria could be part of the BPT process itself... especially if your processes are instantiated based on a new instance of an entity on the database (imagine whenever a new LoanRequest instance record is created, a LoanApplication Process instance starts)

Since you are looking at doing this with an EXTERNAL entity, which can't launch a BPT process on record creation, you can either put this logic into the CRUD wrapper, or start with a condition as the first step of the process that your CRUD wrapper always launches. If you put it into the CRUD wrapper, it means that you will be putting less processes/activities into the queue which will improve BPT performance.

J.Ja

For External entity, in addition of the drawback that external entity"s action cannot be used to trigger implicitly, there will be a chance that when the data manipulation is done by using other tools (say TOAD) to insert record, an activity will not know if that entity action has done.

Indo wrote:

For External entity, in addition of the drawback that external entity"s action cannot be used to trigger implicitly, there will be a chance that when the data manipulation is done by using other tools (say TOAD) to insert record, an activity will not know if that entity action has done.

And this is why I highly do not recommend the exact pattern you describe.

If you are using an external DB table, and other applications access it directly, its logic should either be contained in some sort of service to access it from OutSystems, or in the database itself (stored proc, triggers, etc.) just like any other database-driven application written in any other system because if you don't, and put your logic into the OutSystems application, any thing you need to happen, won't always happen. This isn't an "OutSystems thing", this is a problem regardless of language/technology. If you put your business logic into a Java application, then have a .Net desktop app directly access the DB, you will have the exact same problems.

J.Ja