Question

Looped background task

J
Rank
Badge +3

Hi guys,

I needed to keep two fields between two logical units with the same value at the same time so that the user can edit them in both logical units. I used an event on both fields that triggers when the field is changed. Both events is runnig like background job. 


Event1 triggering when value in object1 is modify in LU1 --> make copy value to object2 in LU2
Event2 triggering when value in object2 is modify in LU2 --> make copy value to object1 in LU1

 

 In 99% of the cases this works fine, but sometimes it happens that these two events get stuck and loop until I turn off one of the events. Anyone have any ideas on how to prevent this cycling? It's clear to me why this occurs, but I would need to be able to have the value of the fields interleave between logical units and at the same time be able to change it anywhere.

If anyone has a better idea I would be grateful.
 Thanks

 

4 replies

J
Rank
Badge +3

For now i tried this 
 

 

B
Rank
Userlevel 3
Badge +8

Hello,

Try to:

  1. Disable your events.
  2. Create one more logical unit with a history of that field.
  3. Create an event that will update the field with the oldest value each time a new LU is inserted.

I hope this will be more stable.

Best regards

Bart

J
Rank
Badge +3

Hi,

thanks for your response, but I don't know if I'm understanding this right, but it seems like it's not gonna solve anything and I'm gonna get the noose again.

If I understand correctly, I'll create a modify event on the first field, where I'll create a new record in the newly created LU. I will do the same for the second field.

And over the newly created LU I will create an event when a new record is added to the LU. And that will ensure that I synchronize the two fields. 

But this seems like a pure loop to me, because once the event over the new LU triggers a modify over a field, it will automatically write itself. The only possibility I can think of is that the event on the new LU wouldn't use the modify function, but would directly use the SQL update event and it wouldn't run the modify event on those fields.

If I misunderstood that, I apologize. And thanks again for the reply.

 

B
Rank
Userlevel 3
Badge +8

Hello,
 

You have a good understanding of the issue, but let's refine the solution by adding another check to ensure we have the newest value in the new LU. The condition for the first event (on LU1) should be:

`&NEW:CF_C_POPIS_WF != &OLD:CF_C_POPIS_WF AND &NEW:CF_C_POPIS_WF != NEW_LU.VALUE AND &NEW:CF_C_POPIS_WF != LU2.CF_C_POPIS_WF`

Similarly, an analogous condition should be added for the second event on LU2 to ensure that the value does not loop back:
`&NEW:CF_C_POPIS_WF != &OLD:CF_C_POPIS_WF AND &NEW:CF_C_POPIS_WF != NEW_LU.VALUE AND &NEW:CF_C_POPIS_WF != LU1.CF_C_POPIS_WF`
 

The conditions as formulated help prevent looping by adding checks that ensure a field's new value is not only different from its previous value but also distinct from the corresponding values in other logical unit. Specifically, each condition checks three things:

1. The value must change (`&NEW:CF_C_POPIS_WF != &OLD:CF_C_POPIS_WF`), which avoids unnecessary triggers if the value hasn't actually been updated.
2. The new value must be different from the value in the new LU (`&NEW:CF_C_POPIS_WF != NEW_LU.VALUE`), helping to maintain consistency across different logical units without redundant updates.
3. The new value must not match the corresponding value in the other logical unit (`&NEW:CF_C_POPIS_WF != LU2.CF_C_POPIS_WF` for the first event and vice versa for the second event), which is critical for ensuring that changes in one logical unit do not cause unnecessary updates in another due to feedback loops.

These checks should effectively prevent the looping issue by making sure that the events are only triggered by genuine changes that need to be synchronized across the units, not by the mere act of copying values back and forth.

Reply


Terms & ConditionsCookie settings