You're welcome. Here's a bit more info about how BPL BPs work. After you compile a BPL BP, two classes get created into the package with the same name as a full BPL class name:
Thread1class contains methods S1, S2, ... SN, which correspond to activities within BPLContextclass has all context variables and also the next state which BPL would execute (i.e.,S5)
Also BPL class is persistent and stores requests currently being processed.
BPL works by executing S methods in a Thread class and correspondingly updating the BPL class table, Context table, and Thread1 table where one message "being processed" is one row in a BPL table. After the request is processed, BPL deletes the BPL, Context, and Thread entries. Since BPL BPs are asynchronous, one BPL job can simultaneously process many requests by saving information between S calls and switching between different requests.
For example, BPL processed one request till it got to a sync activity - waiting for an answer from BO. It would save the current context to disk, with %NextState property (in Thread1 class) set to response activity S method, and work on other requests until BO answers. After BO answers, BPL would load Context into memory and execute the method corresponding to a state saved in %NextState property.
That's why registered objects as context properties can (and would) be lost between states - as they are not persisted.
- Log in to post comments
.png)
.png)
.png)