BO Group objects are incorrectly transferred in Context

nhofkes

Build Number	Database	OS
V10 build 3512	MariaDB 11.3	Windows Server 2016

What I did…

I created BOs that are part of a BO Group. There is a process that takes the BO Group as input and performs an action, for example store the BO in a Session attribute. As a result of the program logic, there may be multiple BOs in the Context which may be of different types within the same Group.

What I expected to happen

I expected the process to take the latest (most recent) BO from the Context as input, in the same way that BOs are taken from the Context that are not part of a Group.

What happened

I found that in some cases, the process does not get the most recent BO as input but an earlier BO. It seems that one type within the Group is more ‘dominant’ than another type. So if first the dominant type is put in Context and then another type is added, the process will get the earlier BO as input instead of the later BO.

Steps to reproduce the problem

I created an example BSV to demonstrate this issue. This builds on the CRM sample application, so to test it you need to have the files in \AwareIM\samples\CRM. When running the BSV, you will first get the usual message that the data will be initialized. Assuming this works correctly, you can then do the following:

Select the tab Correspondence
Select the operation ‘View details’ for Rosemary Flint. This will open a new tab with the name ‘Main’, which has the list of Communication items in the left panel and the details of the selected item in the right panel
Select communication items in the left panel. Selecting any item triggers the process ‘Communication_Select’. This saves the selected item in the Session BO. The form in the right panel is automatically refreshed to show the details of the communication item that is stored in the Session BO.
You may see that in some cases the right panel is updated and displays the details for the selected item, but in some cases it is not updated but instead displays the details of the earlier BO (being in this example the Contact Note for Rosemary Flint). On my computer, this happens for example when I select the outgoing letter to Jane Allison (the first communication item in the left panel).

If in your situation this does not reproduce the problem, you may have to try different combinations. I.e. select one communication type on the Correspondence list (tab ‘Correspondence’) and then select another communication type on the tab ‘Main’. The first step puts that BO in Context and the second selection puts another BO in Context.

Below a screenshot that illustrates the issue. First a ContactNote is put in Context. Subsequently another item is selected of a different type, in this case an OutgoingLetter. But that OutgoingLetter is not delivered as input to the process Communication_Select, but instead the earlier ContactNote. In other words the ContactNote seems to have preference over the OutgoingLetter.

For comparison, here is a screenshot of the log when the same two objects are selected in reverse order. This shows that the issue is not in the object itself, but in the way that the object is taken from the Context.

bogrouptest.bsv

374kB

Attached example BSV

bogrouptest.zip

1kB

Attached log file (as zip file as the Forum does not seem to support .log or .txt files)

Jaymer

If you think it has a “ earlier“ BO, have you tried clearing it with CLEAR CONTEXT?
Have you used LOG2 CONTEXT to see all objects in context?
I use a lot of groups and can’t say I have had any issues.

nhofkes

Jaymer

If you think it has a “ earlier“ BO, have you tried clearing it with CLEAR CONTEXT?

Yes, I tried that but it doesn’t help. CLEAR CONTEXT only allows you to delete all BOs of a certain type, not just the 2nd BO and retain the 1st BO. And using TYPE() doesn’t work either.

Have you used LOG2 CONTEXT to see all objects in context?

Yes, but that gives me the same information that the log already contains.

customaware

Haven’t dug deeply into your exact issue and not sure if this will help but when I am dealing with a situation whereby I need to manage multiple instances of a BO, usually get tangled up with This and That and Other, especially when calling Sub Processes etc.

So, what I do is I create a Non Persistent BO and use that as a carrier.

For example. Imagine I have a BO called Widget and I want to FIND a particular Widget for some date and then I want to FND two more widgets for later dates and then Update those two Widgets with some calculation based on the data from the first Widget.

BO: NP_WidgetManager
Attributes: WidgetManager.Widget1, WidgetManager.Widget2, WidgetManager.Widget3

I CREATE WidgetManager WITH WidgetManager.Widget1 = Widget (this is the primary first Widget
Call whatever Subprocesses are needed to FIND WidgetManager.Widget2 and WidgetManager.Widget3 BUT DO NOT PASS WidgetManager.Widget1 as an Input. Instead, pass NP_WidgetManager
Then FIND Widget2 and WidgetManager.Widget2 = Widget2 and FIND Widget2 and WidgetManager.Widget3 = Widget3

From this point on, you do not need to worry about which Widget is in Context or This or That or Other….

Just pass NP_WidgetManager as an Input

NP_WidgetManager.Widget3.SomeValue = NP_WidgetManager.Widget1.TotalValue * 1.1

etc etc

nhofkes

customaware Yes, I use the same approach in some more complicated cases. In this simple case I used another work-around: store the data in the Session BO and retrieve the same data from the Session by the subsequent process, which therefore does not need any input. I found that if the subsequent process does not have any input, the BO is removed from the Context upon termination of the first process. This solves the problem. However, the fact that there are work-arounds does not take away the fact that this is (almost certainly) a bug that needs to be fixed. It should be possible to have multiple BOs in Context and retrieve them, regardless of whether they are part of a Group or not.

aware_support

Generally speaking the order of business objects in Context is undefined - it is not possible to predict which instance will be used. The only exception to this rule is when Context is populated by an ordered query, for example:

FIND ALL BO ORDER BY BO.Attribute
DoSomething

So when you are referring to the most “recent” BO, what do you mean?

nhofkes

Perhaps I should clarify that the two BO instances are not added to Context by one process. It is the result of two different processes and user interactions. First the user starts a row operation on one BO, and the invoked process receives that BO in Context. Next the user selects another BO in another process and that 2nd BO is also added to the Context (which still had the first BO in Context).

With most “recent” I mean the BO that has been most recently added to the Context. For example if you look at the log in the first screenshot in my original post, you will see that first ContactNote:217 is added to the Context, and subsequently, as a result of a selection made by the user, the OutgoingLetter:591. The log shows that the subsequent process receives both instances in the order ‘OutgoingLetter:591 ContactNote:217’. Thus the log shows the most recently added BO first and the earlier BO second, and this behaviour seems to be consistent in my testing (I did not see any cases where the order was reversed). So in that subsequent process I’d like to use only the most recently selected BO (in this case OutgoingLetter:591) and not the earlier BO (ContactNote:217). Both are part of the ‘Communication’ BO Group, and by using ThisCommunication and ThatCommunication it should be possible to distuingish between the two instances.

Note that if I apply the same approach to two object instances that are of the same type and not part of a BO Group, this would be no problem. I could use one or the other by using the ‘This’ and ‘That’ prefixes. And there is also no problem if the object instances are part of a BO Group and of exactly the same type, this works too (for example selecting two ContactNotes in two different processes). But if the two instances are part of a BO Group but are of a different type (like ContactNote and OutgoingLetter), the ‘This’ and ‘That’ prefixes no longer work when used in combination with the Group description like ‘ThisCommunication’.