[KULRICE-8894] "Synchronous" behavior w/in KRAD Created: 01/Feb/13  Updated: 12/Aug/13  Resolved: 08/Apr/13

Status: Closed
Project: Kuali Rice Development
Component/s: Development, Roadmap
Affects Version/s: 2.2
Fix Version/s: 2.3
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Major
Reporter: William Washington (Inactive) Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to KRRM-141 KRAD Phase 3 - Complete core features... Resolved
is tested by KSENROLL-5346 POC to test synchronous behavior of KEW Closed
User Feedback
is fixed by development issue KULRICE-8559 When routing a doc with no route path... Closed
Rice Module:
KRAD Feature Area:
KEW Integration
Application Requirement:
KAI Review Status: Not Required
KTI Review Status: Not Required
Include in Release Notes?:


"fire and forget"" + audit log

synchronous call to workflow that immediately calls the...

Larry will talk to Dan E. about getting a Rice jira filed. Getting close to having a high level design of fundamental changes needed to the maint framework to hand off to rice.

Comment by William Washington (Inactive) [ 01/Feb/13 ]

[2/1/13 12:00:29 PM] Larry Symms: We need a process for recording (think audit trail) of actions taken on a Data Dicionary based Object.  These actions would be performd on a KRAD form with a button that performs an immediate action without workflow.  The problem we've had implementing this with KEW (which does the logging we need) is that KEW is entirely asynchronous.  We need the action to be taken immediately, even if the auditing is done asynchronously.  Although, I think synchronous on the logging is necessary too.

Comment by Eric Westfall [ 01/Feb/13 ]

If you don't define any routing/approval for a document, it's possible for KEW to process the document synchronously. The KNS didn't really handle that properly (since it assumed document handling was async) but it probably could be coded properly in the KRAD framework.

Essentially, in this case when you use the KEW api to submit/route a document, the document will immediately transition to the "FINAL" status.

Regardless, there's probably a question of whether or not for your specific case if this is really a desirable use of the workflow engine or not.

Comment by William Washington (Inactive) [ 04/Feb/13 ]

Additional comments (I'll also route Larry to this jira so that he can comment himself):

[2/1/13 12:05:48 PM] Larry Symms: [if we] do this ourselves but that would mean providing screens for lookups of transactions which KEW already handles quite nicely

Comment by William Washington (Inactive) [ 05/Feb/13 ]

I need to confirm: (1) that all current page flow issues will be fixed by KULRICE-8894, and (2) how this relates to recent KRAD transactional doc support.

Comment by Matt Sargent [ 06/Feb/13 ]

We need a couple of scenarios or examples of how this would/is desired to work work.


Comment by Peter Giles (Inactive) [ 06/Feb/13 ]

Also useful would be specifics on the unwanted behaviors that this would address.

Comment by Larry Symms [ 06/Feb/13 ]

unwanted behaviors: asynchronous write via post processor in external system causes us to either notify the user that their request is enroute or to do timed polling of KEW to get document status until status is final. This could be managed entirely from our application but we don't get document search or a trail of activity. We'd basically have to duplicate a large chunk of KEW to do that.

Comment by Matt Sargent [ 11/Feb/13 ]

From the meeting today Larry and Co. should try the below for an empty route path...
search that file for "EmptyProcessDocType"
essentially, just define route paths section as: <routePaths/>
for the logging as annotations.

Comment by Matt Sargent [ 11/Feb/13 ]

Eric Westfall: Larry/Dan, here's a code sample showing the workflow api interaction for these documents:


You can see from the test there that it calls document.route and then can immediately ascertain the document has gone final

i also verified that it is infact calling the post processor so you'll get three status transitions: (I)nitiated -> En(R)oute -> (P)rocessed -> (F)inal

Comment by Larry Symms [ 08/Apr/13 ]

Fixed. Will test when KS upgrades to 2.3.0 M1 in April

Generated at Mon Nov 30 20:42:32 CST 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.