Use process interface for sub processes that will probably change internally in the future.
Process interface establishes a contract between parent and sub-process. It is mandatory for dynamic sub-processes but also interesting for sub-processes that can change.
- simplify process migration
- increase reusability & exchangeability
Separate process interfaces of sub processes in other (extra) TIBCO Business Studio? Projects.
This will decouple dynamic sub-processes at runtime and allows deployment of subparts without affecting the main procedures. (?getting out of sync.?)
- simplify deployment
- increase flexibility
Interfaces, and dynamic Subprocedures
There are many reasons of using Interfaces and dynamic Subprocedures
Split against following rules:
- Separate different Business Areas
- Separate different Backends
- Separate different topics i.e. Credit, Check, Contract, etc.
- Reuse for different Main Procedures
- Reuse BOMs where Possible
- Do not use this Interface Pattern for technically Subprocedures that will never change, e.g. BPM Configuration Data loading
Benefit, separation simplifies:
- Working in a Team, especially XPDLs
- Deployment of Projects
- Sub Procedures can be deployed independently.
- Faster Deployment of Updates
- Migration benefit is two-fold:
- No need to migrate short lived sub-procedures when the procedure has changed, the main procedure will automatically call the latest sub-procedure deployed.
- If migration is necessary, ability to migrate processes independent of main processes
- Faster Node startup
... and it add?s flexibility!
- create Sub procedures using Process Interface Projects
- Use a Runtime Identifier Field to specify the Process Path
- Use Initial Value to configure Process Path, avoids later typo?s and issues because of them
- Use for every Subprocess another Runtime Identifier Field
- Store Process Interface, Subprocess, and Main Process into different Projects (here at least 3 BS Projects)
Sample can be found here ...