Split Node and Branching

[Berkoff, Alexis (Alex) Contractor, eDataTech]

Hi “Everybody” –

 

Not sure who is still on this thread (especially now during the Holidays) …

 

Had a question about using split nodes in the workflow.

(workflow via the KEW workflow engine circa KC version 5)

 

Here is my workflow document that I ingest (the part that matters anyway):

 

 

Notice that I have 2 split nodes:  “isProposalNavalResearch” and “isResearchDeanAlsoPIorPD”

So, as the workflow is being evaluated etc, I have some business logic that generates a Boolean value and depending on that value – I’ll continue to traverse the appropriate branch that is part of the split node.

 

Right, so the issue is that my 2^nd split node (isResearchDeanAlsoPIorPD) will evaluate twice if my first split node evaluates to True.  The resultant workflow will contain 2 of the same nodes at the end of the workflow.

 

Here is an example of the scenario above playing out when isProposalNavalResearch => TRUE and isResearchDeanAlsoPIorPD => FALSE.

 

(Yes – I’ve removed names for anonymity)

 

 

Here is an example of the scenario above playing out when isProposalNavalResearch => TRUE and isResearchDeanAlsoPIorPD => TRUE.

(Again, removed names for anonymity)

 

 

So – it seems that the problem is how I’m not joining the branches properly.  But interestingly – this works fine when the first split node evaluates to FALSE.  So I’m not sure if that observation is accurate.

I’m hoping that I don’t have to dig into RICE KEW code – hoping for late Christmas present and someone can tell me that something is off in my XML config file…  😊

 

Thanks.

 

// AB

[Ken Geis]

Hi Alex. I'm happy to see signs of life out there!

I've modeled my splits somewhat differently, and they seem to work without the problem you describe. You might want to try writing them like this:

<split name="isProposalNavalResearch" nextNode="isResearchDeanAlsoPIorPD">
  <branch name="False">
    ...
    <requests name="NPS_VPAA_Approval" nextNode="isProposalNavalResearchJoin"/>
  </branch>
  <branch name="True">
    ...
    <requests name="NrpDepartmentRouting" nextNode="isProposalNavalResearchJoin"/>
  </branch>
  <join name="isProposalNavalResearchJoin"/>
</split>

Best wishes,

Ken

On Dec 26, 2019, at 9:37 PM, Berkoff, Alexis (Alex) Contractor, eDataTech <ambe...@nps.edu> wrote:

Hi “Everybody” –

 

Not sure who is still on this thread (especially now during the Holidays) …

 

Had a question about using split nodes in the workflow.

(workflow via the KEW workflow engine circa KC version 5)

 

Here is my workflow document that I ingest (the part that matters anyway):

 

<image001.png>

 

Notice that I have 2 split nodes:  “isProposalNavalResearch” and “isResearchDeanAlsoPIorPD”

So, as the workflow is being evaluated etc, I have some business logic that generates a Boolean value and depending on that value – I’ll continue to traverse the appropriate branch that is part of the split node.

 

Right, so the issue is that my 2^nd split node (isResearchDeanAlsoPIorPD) will evaluate twice if my first split node evaluates to True.  The resultant workflow will contain 2 of the same nodes at the end of the workflow.

 

Here is an example of the scenario above playing out when isProposalNavalResearch => TRUE and isResearchDeanAlsoPIorPD => FALSE.

 

(Yes – I’ve removed names for anonymity)

<image002.png>

 

 

Here is an example of the scenario above playing out when isProposalNavalResearch => TRUE and isResearchDeanAlsoPIorPD => TRUE.

(Again, removed names for anonymity)

<image003.png>

 

 

So – it seems that the problem is how I’m not joining the branches properly.  But interestingly – this works fine when the first split node evaluates to FALSE.  So I’m not sure if that observation is accurate.

I’m hoping that I don’t have to dig into RICE KEW code – hoping for late Christmas present and someone can tell me that something is off in my XML config file…  😊

 

Thanks.

 

// AB

-- 

--- 
To unsubscribe from this group and stop receiving emails from it, send an email to kc.collab+...@kuali.org.

Ken Geis (he/him/his) 

Software Applications Programmer 
Research Administration and Compliance 
University of California, Berkeley 
LinkedIn | rac.berkeley.edu | berkeley.edu

[Berkoff, Alexis (Alex) Contractor, eDataTech]

Hi Ken!

 

Indeed – I exist.   😊

Thanks for your response.

I’ve refactored my XML workflow config to match your syntax.

 

 

Unfortunately, I’m still getting the same result.

 

The funny thing is that when I swap the True and False branches in that first split node, whichever branch is on the bottom will cause the issue!

In the above scenario as I have it now – when the first split node is TRUE, then the second split node will get called twice!

So, the simulated workflow will show either 2 deans at the end or 2 provosts. 

I did actually confirm stepping through the workflow that either the dean or provost would still only have to APPROVE once (so the first Approve clears out the second one).

But having that last node show up twice in the simulated workflow is going to annoy folks…

 

How strange is that? 

 

Follow on question:

How did you define your SplitNode in the <routeNodes> section?

 

I did this:

 

<split name="isProposalNavalResearch">

    <type>org.kuali.kra.kew.SimpleBooleanSplitNode</type>

</split>

 

Also, what version of RICE are you using?  (I’m using 2.1.5).

 

I’m starting to think that there is a bug in my version of the KEW Rice code. 

 

Alex

[Akers Jr,Allen]

I’m not in the office right now, but just wanted to throw out that I was having issues with a split in kew workflow because I was using one of the out-of-the-box example workflows as my template. It stated that it was (I believe, from memory) workflow version 1 and when I changed that to 2 then it resolved the issue and the split worked properly after that. I’ve always thought the splits/joins were far too fragile, but just wanted to throw that issue out there in case that is what is also tripping you. 

On Dec 27, 2019, at 11:42 AM, Berkoff, Alexis (Alex) Contractor, eDataTech <ambe...@nps.edu> wrote:



Hi Ken!

 

Indeed – I exist.   😊

Thanks for your response.

I’ve refactored my XML workflow config to match your syntax.

 

<image001.png>

--
To unsubscribe from this group and stop receiving emails from it, send an email to kc.technical.co...@kuali.org.

[Berkoff, Alexis (Alex) Contractor, eDataTech]

Hey Allen –

 

Do you remember where you changed the version number?

I don’t see that attribute on the template I’m using…

[Akers Jr,Allen]

<routingVersion>2</routingVersion>

 

Not sure what the default would be if it isn’t included, but you might try adding that element if it doesn’t exist at all, just to be sure.

[Costea Ibanez, Natalia - (nataliac)]

Hi Alex!

We're also using split nodes for routing proposals and we didn't encounter the problem you mentioned.

However, we do have the routing version set to 2, just before the <routePaths> element:

 

<routingVersion>2</routingVersion>
      <routePaths>

      .....

     </routePaths>

Natalia Costea Ibanez

Applications Systems Analyst/Developer Pr.
UAccess Research Administration - Kuali Coeus
Kuali Applications Support Team
UITS Enterprise Applications - University of Arizona
(856)-701-6540

---

From: Akers Jr,Allen <Allen...@colostate.edu>
Sent: Monday, December 30, 2019 8:15 AM

To: Berkoff, Alexis (Alex) Contractor, eDataTech <ambe...@nps.edu>

Cc: Ken Geis <kg...@berkeley.edu>; kc.techni...@kuali.org <kc.techni...@kuali.org>; kc.c...@kuali.org <kc.c...@kuali.org>

[Berkoff, Alexis (Alex) Contractor, eDataTech]

Thanks to everyone’s responses.

Unfortunately I’m still running into the same issue.  So, I needed to resort to modifying the RICE KEW code.

I solved the issue by modifying the StandardWorkflowEngine class by adding an additional conditional in the code that “adds” workflow nodes to the chain.

Actually, I’m a bit surprised that the isFinal attribute wasn’t being used here to begin with.

 

 

I set the value for the workflow node in the configuration file itself like this:

 

 

Since the issue was occurring at the end of the workflow – this works for our use case. 

However, WHY this was happening is still a mystery and frankly not something I care to invest more time in debugging unless our use cases required it.

 

Happy New Years!

 

// AB

[Ronald Gouldner]

Alexis,  

Sorry I missed your thread.  Glad to see you solved the problem.   I would have thought you needed to join the node before moving on so the "duplicate" would be the do nothing join as Ken suggested.   I am surprised that didn't work.  

However, we don't use split nodes because we use custom code we wrote to make route stops more flexible.

So, Replying just to return the Happy New Year and to agree with Ken's sentiments that it is nice to see there is still life out there.  Perhaps the community can be revived a bit in 2020 :)

Ron