Best practice for structuring code statements in rules

Just a thought... In a process having multiple steps, is there any difference in placing all of the steps in the same rule vs. placing them in separate rules? I know there may be times when separate rules may be necessary, such as with IF/THEN logic, but what about when it's just a number of steps? I ask because I have a process that occasionally does not complete one of the intermediate steps in a rule and I wonder if separating the steps into individual rules may make a difference. I would imagine in the final java code, it's no different. Thoughts?

Hi Kingsley,

For me, it depends if they are BO Rules or Process Rules.

Over the years I have tended to, wherever possible move BO Rules out to a Process whenever I specifically want the Rules processed in a particular order. I know there is the option of setting a Priority on the BO Rule but that just adds another layer of complexity in my book.

More specifically to you question... I guess, it depends....

When I first started with Aware I always tried to keep Processes and Rules as compact as I thought possible but found that it is actually more complicated to later understand exactly what is happening. I did not want to create to many processes and sub-processes. But now, I have no hesitation at all in creating many many sub-processes which provides more clarity of logic and also has the advantage of ALWAYS knowing what BO instances are in context.

When I am building a workflow that has a lot of complex logic in it I always now use the Worksheets functionality which is fantastic and allows me to keep everything I need for that workflow in one place rather than needing to jump around all over the place trying to remember whats what and also allows me to check off the parts that are complete, tested and working properly.

Additionally over the last few years, I have made much more use of SEARCH_COUNT to ensure correct and dependable execution of particular rules whereas in my earlier Aware experience I was relying to much on a FIND to actually FIND something. Of course, the trip hazard there (which I learned way to late after a serious bug) is that if you have, for example a sub-process call immediately after a FIND expecting it to execute the sub-process for each record found, Aware will execute the sub-process when the FIND fails to find any records.

But, I digress. Back to you point...... I tend to seperate Rules as much as possible purely to be able to give them a descriptive name that makes sense when I need to understand the logic in the future.

The funny thing is..... I have been using Aware for 13 years now and at times when I come across some stuff I did years ago.... there are so many things I look at now and go...." What the hell was I thinking :-/

Just as a little tip that might help other while I am at it....

When you have a Process with multiple sub-processes... Grand Parent / Parent / Child / Grandchild process structures..... I found it helps enormously to maintain a strict Process Naming convention that can be easily followed at a later time..... for example....

The Grand Parent Process name start with a common part which is as short as possible....and a _1 suffix
Let's say MyWorkFlow_1_FIND_Employees. Now, say, from that I need two sub-processes... I just copy and paste this Process which will automatically be named MyWorkFlow_1_FIND_Employees1 and MyWorkFlow_1_FIND_Employees2. I then rename those to MyWorkFlow_2_FIND_WorkHistory and MyWorkFlow_3_CalcWorkHours.... and on and on for each sub-Process.....
I think use Display Under for each sub-process which effectively keeps everything together in a nice tree like structure providing further clarity in the future. But the main thing is that EVERY Process and sub-process in that entire Workflow ALWAYS starts with MyWorkFlow or whatever. I do wish Aware would allow longer Process names as sometimes if get hard to name the Processes something meaningful within the maximum Process Name length.

I would love to hear what naming conventions others have employed as I am sure there are smarter ways of doing this but my pea sized brain just could not think of any.

Anyway... hope it helps.

I proved this and documented it years ago, but one thing to keep in mind is it every time you send a record to a sub process, naming that record as an input to the sub process,
Aware is physically rereading that and all of its shortcuts from the database.
It may be obvious, it may not be.
And if it’s a large BO, it’s got to read that entire flattened view because aware has no idea if you’re going to or not use every one of those fields in the flat view.
So it has no choice but to read them all.
The recent addition of not resolving shortcuts only applies to grids.

And with regards to resolving shortcuts, if you have a main BO with a single peer reference to BO2, then it really doesn’t matter if you have one or 10 or 20 shortcuts to BO2, there is no additional database overhead for those extra shortcuts.
It’s still only gonna read that table ONCE and then assign your shortcuts/fields from that one database read.

Thanks guys. I’m still struggling to find why my process sometimes fails to complete one or more steps.
Here’s the whole process. The three (*) items sometimes fail to complete. Failures are rare, but they do occur. These three processes establish the login name, password, and expiry date for the user.

*Reference.LoginName=Reference.PHS.Candidate.Organization.AccountCode+`REF`+Reference.ID (sometimes fails and no value is set)
Reference.Access_ClearPassword=GENERATE_PWD(8,8,0,8,0) 
*Reference.Password=Reference.Access_ClearPassword (sometimes fails and the user's password does not work)
*Reference.Access_AccessThroughDate=CURRENT_DATE+LoggedInInvestigator.Organization.ResponseDaysReference (sometimes fails and no value is set)

*/ All items below always run fine /*

CREATE Journal WITH Journal.TimeStamp=CURRENT_TIMESTAMP,Journal.CandidateName=Reference.PHS.Candidate.FullName,Journal.PHS=Reference.PHS,Journal.ActionBy=LoggedInInvestigator.FullName,Journal.Action='System access granted to Reference '+Reference.FullName,Journal.Candidate=Reference.PHS.Candidate 
CREATE Waitlist WITH 
 Waitlist.Reference=Reference,
 Waitlist.PHS=Reference.PHS,
 Waitlist.Item='Personal Reference Questionnaire',
 Waitlist.Person=Reference.FullName,
 Waitlist.StartDate=CURRENT_DATE,
 Waitlist.DueDate=Reference.Access_AccessThroughDate,
 Waitlist.RelationType=Reference.Relationship,
 Waitlist.Investigator=Reference.PHS.Investigator,
 Waitlist.Candidate=Reference.PHS.Candidate 
ThisReference.Invited=CURRENT_DATE 
ThisReference.Access_GrantedDate=CURRENT_DATE 
ThisReference.Access_Renew='Yes' 
 FIND PHS WHERE PHS=Reference.PHS
 FIND Organization WHERE Organization=PHS.Organization
 FIND Candidate WHERE Candidate=PHS.Candidate
 FIND Investigator WHERE Investigator=PHS.Investigator
 SEND WelcomeReference TO Reference 
 SEND WelcomeReferenceCCInvestigator to Investigator
ThisReference.Access_ClearPassword='' 
 SetCaseInProgress

kklosson* Reference.LoginName=Reference.PHS.Candidate.Organization.AccountCode+REF+Reference.ID (sometimes fails and no value is set)
Reference.Access_ClearPassword=GENERATE_PWD(8,8,0,8,0)
Reference.Password=Reference.Access_ClearPassword (sometimes fails and the user’s password does not work)
Reference.Access_AccessThroughDate=CURRENT_DATE+LoggedInInvestigator.Organization.ResponseDaysReference (sometimes fails and no value is set)

Could it be that GENERATE_PWD is creating some special character that ClearPassword is ok with but Password doesn’t like?

Also wouldn’t CURRENT_DATE+LoggedInInvestigator.Organization.ResponseDaysReference be better written as DATE_ADD(CURRENT_DATE,LoggedInInvestigator.Organization.ResponseDaysReference)

Mark, you said:
The Grand Parent Process name start with a common part which is as short as possible....and a _1 suffix
Let's say MyWorkFlow_1_FIND_Employees. Now, say, from that I need two sub-processes... I just copy and paste this Process

I don't copy the process, since I then have to delete all the lines in the new process. Instead I copy the NAME of the process, create a new process and paste that name and then edit that name.

Bruce

Yes.... I get your point Bruce....
However, I copy the whole process purely so I don't need to go back and look what is in context and can easily identify what should be input from the Parent.

No big deal to delete the Rules that are no longer needed.

Given I have several statements in a row that are pure actions, would y’all agree that whether the statements are all in one rule or in separate rules, they result in the same code execution?

As is, I have several actions in one rule, and I occasionally experience some actions not completed. Would it possibly be any different if I placed them in separate rules?

kklosson

Split it into separate rules, even though it might essentially work the same having it split will force Aware to do things in order as it usually runs rule by rule from the top to bottom.

Another thought could be that multiple actions are trying to use the “Reference” object at the same time which could cause the database to get “locked” even for a few extra microseconds and could be causing the fields to be blank, could be better to run all the Reference updates in a separate rule before running all the others.

One issue I have found before in 8.8 was that if you have more than 4 IF statements in 1 rule in a process it will only check the first few and completely ignore the rest but this was not an issue in the Update Rules of the object. Haven’t tested this in 9.0 yet.

So in the end could be because too much is happening at the same time.

rocketman

In my experience, the password field doesn’t work at all with characters like å ä ö, so I imagine that some special characters can cause problems as well.