It there command action to Clear Context? (SOLVED)

ddumas

I have attached a screenshot of a process that FINDs an instance of a SendMemberMessages BO, does other stuff with that BO, and then CREATEs another instance of the same BO. Just before the CREATE of the 2nd instance, I need to first "clear" the context of that first instance of that BO. This is because when I RUN Process USING BO, as the last step, its sending both instances to the process, and I only want to send the most recent instance from the CREATE.

Dave

Jaymer

CLEAR CONTEXT new command needed. Here's why

PointsWell

ddumas wrote
I have attached a screenshot of a process that FINDs an instance of a SendMemberMessages BO, does other stuff with that BO, and then CREATEs another instance of the same BO. Just before the CREATE of the 2nd instance, I need to first "clear" the context of that first instance of that BO. This is because when I RUN Process USING BO, as the last step, its sending both instances to the process, and I only want to send the most recent instance from the CREATE.

Dave

There are multiple ways that you can fix this.

The simplest is to just pass the create process off to a sub process. If you then need that newly created BO back for subsequent processing you can create a non persisted BO as a hook.

Eg.
Process 1
... CREATE TempBO

Process 2
Input - Temp BO
CREATE SendMemberMessages WITH ...
TempBO.psSMM=SendMemberMessages

Process 2 ends and reverts to Process 1, you then have the SendMemberMessages in contexts and distinguishable. If you need attraibutes from the original BO you could create multiple peer single attributes in the TempBO eg TempBO.psSMMOriginal and TempBO.psSMMNew

Don't forget that you can effectively drop BOs from context by starting a new process that they are not inputs to. If you use the TempBO as the carrier between the processes you are dropping the original BO from Context whilst still retaining access to it.

Just be mindful that you need to keep passing the TempBO to wherever you need it though and its persistence will end once that process finishes.

ddumas

This sounds interesting, but I am not understanding the concept of a temporary non-persisted BO, or a concept of a subprocess and reverting back to another process.

So far, I understand how to:

Model a BO in the config tool, Let's call that TempBO
When I issue a CREATE TempBO, even via a PROCESS, it always persists in the database.
RUN Process USING TempBO

Can you explain a bit more?

Dave

PointsWell

ddumas wrote
This sounds interesting, but I am not understanding the concept of a temporary non-persisted BO, or a concept of a subprocess and reverting back to another process.

So far, I understand how to:

Model a BO in the config tool, Let's call that TempBO
When I issue a CREATE TempBO, even via a PROCESS, it always persists in the database.
RUN Process USING TempBO

Can you explain a bit more?

Dave

There are multiple types of BO:

Database AwareIM
Database External
LDAP
Not Persisted

Screen Shot 2019-12-13 at 14.43.22.png

Non persisted BOs exist only for the time that the process that created them runs. Consider them as akin to temporary variables (they aren't but you can pretend).

Create a BO that is non persisted, and give it a peer single attribute for your SendMemberMessages

So Process1 looks like

CREATE TempBO
Process2

Process 2 takes TempBO as an input

CREATE SendMemberMessage WITH [all your attribute values]
TempBO.psSMM=SendMemberMessage

At the end of Process2 control will return to Process1. You can chain multiple processes together. This is necessary where for example you do a FIND which returns more than one BO onto which you need to do other operations.

eg FIND all StudentExams returns 25 results. If you want to apply a grade based on the exam score you need to look at each one individually. The only way to achieve that is to create a subprocess (ie another process that you call from the current process). The subprocess when it runs would receive StudentExam as an input and these would be fed to the process one at a time.
This is obviously an example - there's more efficient ways to do this but I needed an example.

There is greater opportunity for code reuse if you make your processes smaller and allow them to be called from other processes when needed.

For example: If you can call an external API from multiple places, write the code for calling the API within one process and then reuse that process every time you want to call the API. This reduces the risk of typos etc.

ddumas

That's perfect, I like the TEMPBOs - can use them to shuttle data around between processes. And a "subprocess" is just a process called within a process. Kind of like executing a stored proc within a stored proc, where execution returns to the calling stored proc. I love it.
Thanks!
Dave

ddumas

Calling the process (subprocess) within the (main) process worked great!
thanks,
Dave