I am having an understanding issue with process rules and relationships
I have tried to do this in a couple of different ways but I still don't think I am understanding all the concepts
I have two BOs - Accounts and Worksheets - for every account there will be at most one Worksheet entry( I made these a peer relationship).
On login - the user lands on a presentation with their account details (I am thinking that Accounts in in Context). I have created a hyperlink for their Financial Worksheet - they click on a link and they currently get a pop-up "Select Process Input" that shows the worksheet in table form.
What I would like is an Edit Form where they can update the values in the worksheet
my logic goes something like this
IF Worksheet EXISTS WHERE(Worksheet.AccountFW=Account) THEN
EDIT Worksheet WHERE Worksheet.AccountFW=Account
ELSE
ENTER NEW Worksheet.AccountFW=Account USING WkshMain
I am greatful any guidance on the rule logic/syntax as well as any insights on how putting BOs and multiple related BOs in Context helps with processes
Help with "Select Process Input"
thom,
I usually suggest the singular name for BOs: Account, Worksheet. This will come in handy with some of the automatic configuration that happens with AwareIM.
A couple of tangent questions for you:
1) Is Account a member of the SystemUser group? This is significant because if Account IS in the SystemUser group, it is ALWAYS in context by using LoggedInAccount...
2) Can a Worksheet be related to more than one Account? If not, I suggest that Worksheet be owned by Account.
Now re: "my logic goes something like this..."
IF Worksheet EXISTS WHERE(Worksheet.AccountFW=Account) THEN
FIND Worksheet WHERE(Worksheet.AccountFW=Account)
EDIT Worksheet WHERE Worksheet.AccountFW=Account
ELSE
ENTER NEW Worksheet.AccountFW=Account USING WkshMain
Adding the bold section should make the "Select Process Input" prompt go away. Without the FIND, AwareIM has not idea which Worksheet you are trying to edit, so it asks you to choose one.
Tom
I usually suggest the singular name for BOs: Account, Worksheet. This will come in handy with some of the automatic configuration that happens with AwareIM.
A couple of tangent questions for you:
1) Is Account a member of the SystemUser group? This is significant because if Account IS in the SystemUser group, it is ALWAYS in context by using LoggedInAccount...
2) Can a Worksheet be related to more than one Account? If not, I suggest that Worksheet be owned by Account.
Now re: "my logic goes something like this..."
IF Worksheet EXISTS WHERE(Worksheet.AccountFW=Account) THEN
FIND Worksheet WHERE(Worksheet.AccountFW=Account)
EDIT Worksheet WHERE Worksheet.AccountFW=Account
ELSE
ENTER NEW Worksheet.AccountFW=Account USING WkshMain
Adding the bold section should make the "Select Process Input" prompt go away. Without the FIND, AwareIM has not idea which Worksheet you are trying to edit, so it asks you to choose one.
Tom
Tom - V8.8 build 3137 - MySql / PostGres
Hi Tom
1. Yes the Account is a member of the System User Group ....
2. Sorry, I had the FIND line in RULE, missed putting it into the post
I got this to work, when I took Account out of the INPUT PROCESS objects in the rule. IT was obvious once you stated it - I realize the message you get when saving a rule were things are not in context is misleading to object references that are part of the SystemUser Group.
My reasoning (right or wrong) for having another BO for worksheet was that it contains just about 100 attributes - the Account BO already has 125+. Do you know of any issues to having BOs contain 200-300 attributes?
Some old database habits(sybase 4) makes me want to split this BOs into organized attributes by requirement, but if Aware can handle it, and it is more efficient why not throw them all into one BO
Lastly - thanks for your thoughts - they are appreciated
thom
1. Yes the Account is a member of the System User Group ....
2. Sorry, I had the FIND line in RULE, missed putting it into the post
I got this to work, when I took Account out of the INPUT PROCESS objects in the rule. IT was obvious once you stated it - I realize the message you get when saving a rule were things are not in context is misleading to object references that are part of the SystemUser Group.
My reasoning (right or wrong) for having another BO for worksheet was that it contains just about 100 attributes - the Account BO already has 125+. Do you know of any issues to having BOs contain 200-300 attributes?
Some old database habits(sybase 4) makes me want to split this BOs into organized attributes by requirement, but if Aware can handle it, and it is more efficient why not throw them all into one BO
Lastly - thanks for your thoughts - they are appreciated
thom