Repeating FIND Action Returns Original Result Set?

[bkonia]

I've created a system using an AttachmentPointer BO which points to an AttachmentDocument BO. The AttachmentPointer BO contains the attribute OrderNumber. I store the actual attachments in the AttachmentDocument BO and attach records from AttachPointer to emails. This allows me to attach the same document to multiple emails, since I'm only attaching a pointer, rather than the actual document and the pointers can maintain independent OrderNumbers. Ridiculously complicated, but it should work...in theory!

Anyway, I'm experiencing a problem when I try to copy the the documents into the OutboundEmail notification. I'm copying each document in an independent rule using a FIND action unique to the document. However, when it sends out the email, I receive three attachments and all three are the same document. It appears as though when you execute a FIND action on a BO and then execute another FIND action on the same BO in a later rule, it ignores the second FIND and continues to use the result set from the first FIND. Here's the specific example I'm referring to:

Rule 1: FIND AttachmentPointer WHERE AttachmentPointer IN OutgoingEmail.AttachmentPointers AND AttachmentPointer.OrderNumber=1
OutboundEmail.Attachment1=AttachmentPointer.AttachmentDocument.Document

Rule 2: FIND AttachmentPointer WHERE AttachmentPointer IN OutgoingEmail.AttachmentPointers AND AttachmentPointer.OrderNumber=2
OutboundEmail.Attachment2=AttachmentPointer.AttachmentDocument.Document

Rule 3: FIND AttachmentPointer WHERE AttachmentPointer IN OutgoingEmail.AttachmentPointers AND AttachmentPointer.OrderNumber=3
OutboundEmail.Attachment3=AttachmentPointer.AttachmentDocument.Docume

I added two (not three) attachments to an email and sent it out. I also verified that the two documents I had attached were in fact different and that they were each stored in the database with a separate OrderNumber. The first document was stored with OrderNumber=1 and the second document was stored with OrderNumber=2. However, when I received the email, it contained three copies of the attachment from Rule 1.

Therefore, as I stated above, it appears as though Aware IM is ignoring the FIND action in Rules 2 and 3 and re-using the result set from Rule 1 for the subsequent rules.

[tford]

Brad,

I wonder if this is caused by the same issue I just reported at http://www.awareim.com/forum/viewtopic.php?t=1465 ?

Tom

[aware_support]

No, this is not caused by the same issue. You need to distinguish the instances of AttachmentPointer using This and That prefixes. Otherwise Aware IM does not know which instance it is supposed to use. So after the first FIND you should write OutboundEmail.Attachment1 = ThisAttachmentPointer....

After the second FIND - ThatAttachmentPointer. As far as the third one is concerned - you have to move the third FIND and the subsequent assignment into a separate process.

[bkonia]

As far as the third one is concerned - you have to move the third FIND and the subsequent assignment into a separate process.

Let's say I create another process called "AddAttachment" and I call this from the SendEmail process using the "Process Call Action". In the Process Input for AddAttachment, I can specify OutgoingEmail, but there's no way to specify the OutboundEmail notification as an input.

Another potential problem I see is that according to the documentation, the called process automatically inherits the context of the calling process. Therefore, wouldn't AddAttachement inherit the existing AttachmentPointer instances from the SendEmail process? In that case, we'd be back to square one...

[aware_support]

A process does not inherit the context of the calling process.

Regarding the problem - please disregard my previous recommendation - it's wrong. The correct solution is to have rules 1, 2 and 3 as independent rules attached to the OutboundEmail notification (when it is created). Each rule will be executed in its own context and so there will be no conflict between instances.

[bkonia]

Yes, your solution worked perfectly. Thanks!

I am, however, a bit confused about your statement that "A process does not inherit the context of the calling process." The documentation for the "Process Call" action states the following:

"If a process requires process input then instances of the business objects representing the process input will be automatically taken from the current Context when the action is executed (see the Context of Rule Execution section)."

If a process is calling another process, where else would the Context come from, other than the calling process?

[aware_support]

Yes, this is true for process input - certainly the instances are taken from the context of the calling process. Instances of other objects are not inhertited, though, and that is what I meant in the previous e-mail. Sorry to have confused you in some of the posts - I must have been having a bad day. Please disregard my posts on the matter except the one that gives you the right solution.