Navigation after create

rgates@ttcdas.com

How do you navigate to a record created via the Create statement from within a process.

I have a data entry form that on change of one of the fields will result in a duplicate record being created. I accomplish this by executing a process within a rule from the currently referenced BO The process uses the CREATE function to create the new BO. Once the object is created, I would like the user to be presented the new BO in Edit mode. I have tried the EDIT BO right after the create, but Aware doesn't like that.

How should I implement this type of functionality?

BobK

Try

ENTER NEW BO WITH BO.attribute = 'value'

thom

rgates,

this is definitely a tough one. I played around for a bit trying to get this one to work and I couldn't

If I understand this correctly, you have a "WAS CHANGED" rule on a attribute. The rule creates a "duplicate" record. I got this to work with both a CREATE and an ENTER NEW. The problem comes when you want to edit the dup record you just created.

We need to find a way to change the existing context to another instance of the same BO - Aware does not seem to let you change the context in mid process.

rgates@ttcdas.com

Yes, ENTER NEW and CREATE both result in the same error regarding user interaction.

In the past what I have done is just present the user with a query showing the record that was just created. While this works, it is a bit cumbersome.

tford

I have not tested this, but here are some thoughts.

1) Instead of having the WAS CHANGED rule try to create a duplicate record & then EDIT it.... have the rule just create the duplicate record and set a flag in RegularUser BO that it was created. You could also store the ID of the newly created instance.

2) In the process that's running your data entry form, add another step to look for the RegularUser flag and ID. If the flag exists, then VIEW the newly created instance. At the end of this process, you should also clear the flag.

rgates@ttcdas.com

Hi Tom.

I'm a little confused how this is any different then what I am doing. Right now the only thing the rule WAS CHANGED is doing within the BO is calling the process. The process itself CREATES the record and then tries to EDIT it. I originally had the CREATE in the BO rule, but thought that might of been the problem so that is why I moved the CREATE to the process.

thom

Tom,

your suggestion was the same angle I was working, although I was using systemsettings to hold my newid - still i could not get it to work, but I'll drop the WAS CHANGED rule and try using RegularUser

tford

Thom,

From your earlier post:

We need to find a way to change the existing context to another instance of the same BO - Aware does not seem to let you change the context in mid process

Have you tries THIS or THAT prefixes?

thom

I did use THIS but not THAT ....never ran into a case where i needed THAT. Just as good of time as any to discover its usage.

tford

Be careful in your usage of THIS and THAT .... check out the User Guide. THIS is for the first instance of the BO put into context & THAT is for the second instance of the BO put into context.

thom

Tom,

I got this to work (outside of the WAS CHANGED) using THIS and THAT. It was pretty straight forward with your coaching.

2 Step Process(pDupRecord)
1). CREATE NEW BO WITH BO.ATTR1=ThisBO.ATTR1, BO.ATTR2=ThisBO.ATTR2,...
2). EDIT ThatBO USING MAIN (you can also use VIEW ThatBO...)

now, when I call this process from a rule
IF BO.ATTR3 WAS CHANGED Then pDupRecord

I get a error message "Unable to edit/view unresolved object"

tford

My understanding is that you can NOT initiate UI stuff from rules.... either directly or indirectly.

tford

Try this:

BO attributes:
1) RegularUser.BOid - Number type
2) BO.Att1 - Plain Text
3) BO.Copy - Yes/No

BO rule:
If BO.Copy='Yes' Then
CREATE BO WITH BO.Att1=BO.Att1,BO.Copy='No'
LoggedInRegularUser.BOid=ThatBO.ID

Process:
LoggedInRegularUser.BOid=0

VIEW BO USING Main

If LoggedInRegularUser.BOid<>0 Then
FIND BO WHERE BO.ID=LoggedInRegularUser.BOid

If LoggedInRegularUser.BOid<>0 Then
VIEW BO USING Main

*** Run this process from a Query that lists all BO instances.

technopak

Hi,

If I'm understanding what you are trying to do, this is how I'd do it -

Create a SystemSettings attribute of type YourObject - ie a reference.
Create a rule on YourObject which sets the SystemSettings.YourObjectRef attribute to your newly created (or edited) object.
Use a FIND action to put the object referenced in SystemSettings in context.
Edit YourObject

So, YourObject should have a rule like this -

IF YourObject IS NEW THEN
SystemSettings.YourObjectRef=YourObject

and your process should contain the following rules -

ENTER NEW YourObject using Main
FIND YourObject WHERE SystemSettings.YourObjectRef = YourObject
Edit YourObject

You can also apply this technique to edited objects. The key thing is that you cannot call a user interaction from within the rules of an object - hence the need to finish off the create process before you edit the object.

This works for me anyway 🙂

Peter

tford

Sounds like you are are the right track, Peter.

I always store variables like this in LoggedInRegularUser & not SystemSettings though.

In a multi-user scenario, you could theoretically end up editing another user's record is you store it in SystemSettings.

technopak

You are 100% right there Tom,

In a multi-user environment, your point is right on the money !

Hope between us we've shown a solution 🙂

Peter

rgates@ttcdas.com

Currently my process has these commands. I still get the interaction error. I just simplified the process by telling it to edit a specific record for testing purposes. What am I doing wrong? The way I see it, it is always going to result in user interaction if I execute the EDIT within the process regardless of what approach I use "FIND" the object.

Possibly I misunderstood your post.

These are the commands in the process:

CREATE SMA_Renewal WITH SMA_Renewal.CO=ThisSMA_Renewal.CO,SMA_Renewal.COCompanyName=ThisSMA_Renewal.COCompanyName,SMA_Renewal.COLine=ThisSMA_Renewal.COLine,SMA_Renewal.Item=ThisSMA_Renewal.Item,SMA_Renewal.Renewal_Start_Date=ThisSMA_Renewal.Renewal_End_Date,SMA_Renewal.Status='Active',SMA_Renewal.X_Contact=ThisSMA_Renewal.X_Contact,SMA_Renewal.COCustNo=ThisSMA_Renewal.COCustNo

FIND SMA_Renewal WHERE SMA_Renewal.ID=178061

EDIT SMA_Renewal

tford

rgates,

Please note that in both my explanation & Peter's explanation, there is both a Rule and a Process. Your description does not seem to include both of these elements.

rgates@ttcdas.com

The RULE is in the BO:

If SMA_Renewal.Status WAS CHANGED TO 'Renewed' Then

pCreateSMA_Renewal

tford

You have the CREATE in the Process rather than in the Rule as shown in my example. I suggest following the model of my example.... it works.