Problem updating workitem

[Doug Bryant]

We have a case where some fields on a running ruote process need to be updated.  The use case is simply applying new or updated values to specified workitem fields - no need to advance or alter the workflow further than that.

The StorageParticipant#update(workitem)  looked like it would do exactly what was needed, but it results in an object being nil error.  

I was able to reproduce the error in a test which follows the basic steps of how I was trying to apply an update.

Error:

 1) Error:

test_update_workitem_alt(FtStorageParticipantTest):

NoMethodError: undefined method `[]' for nil:NilClass

    /Users/doug/src/ruote/lib/ruote/storage/hash_storage.rb:98:in `block in get'

Test (add to ft_20_storage_participant.rb to quickly test): 

  def test_update_workitem_alt

    @dashboard.register_participant 'alpha', Ruote::StorageParticipant

    wfid = @dashboard.launch(Ruote.process_definition { alpha })

    wait_for(:alpha)

    wi = @dashboard.process(wfid).workitems.first

    alpha = @dashboard.participant(wi.participant_name)

    wi.set_field('my_field', 'abc123')

    alpha.update(wi)

    assert_equal 'abc123', @dashboard.process(wfid).workitems.first.fields['my_field']

  end

[John Mettraux]

On Fri, Jun 14, 2013 at 09:22:32AM -0700, Doug Bryant wrote:
> (nothing)

Hello Doug,

> We have a case where some fields on a running ruote process need to be
> updated. The use case is simply applying new or updated values to
> specified workitem fields - no need to advance or alter the workflow
> further than that.
>
> The StorageParticipant#update(workitem) looked like it would do exactly
> what was needed, but it results in an object being nil error.
>
> I was able to reproduce the error in a test which follows the basic steps
> of how I was trying to apply an update.
>
> Error:
> 1) Error:
> test_update_workitem_alt(FtStorageParticipantTest):
> NoMethodError: undefined method `[]' for nil:NilClass
> /Users/doug/src/ruote/lib/ruote/storage/hash_storage.rb:98:in `block in
> get'
>

> (...)

OK, so I have hopefully enhanced the warning on #workitems:

https://github.com/jmettraux/ruote/commit/8115610755d


Here is your test reworked to use the storage participant in the way it was
intended to be used:

https://gist.github.com/jmettraux/5785678

I will investigate the first error you encountered even if it resulted from a
storage participant misuse. Since #workitems returns the workitems as they
were right when the participant got applied (before dispatchment), they're
probably still flagged with the fei of the parent expression.


Best regards, have a nice week-end,

--
John Mettraux - http://lambda.io/jmettraux

[Doug Bryant]

Thank you for the clarification.  I didn't realize it was a previous version of the workitem.  The updated documentation make it clearer.

So if the process_status#workitems returns the workitems as they were at the time they were sent *out* to the participants, does the process_status#stored_workitems return the workitems that are currently *in* the participant?

I just notice the StorageParticipant has a #by_wfid method which seems to be a viable way to fetch current workitems by wfid.  For this particular case of having to update certain workitem fields in a running process, I know the wfid ahead of time.   I ended up coding it the original way to prevent having to keep track of an additional field identifier we use to associate workflows with individual records.

Seeing now that process_status#workitems returns the workitem as they were sent out, from the docs, I would expect #update(workitem) to return true indicating the workitem is gone and a newer version available.  I never figured out why it was erroring out.  When you find that issue, please let me know.  I'm curious as to what it ultimately was.

Thanks again for the help. 

Have a good weekend

--
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
---
You received this message because you are subscribed to the Google Groups "ruote" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwferu-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Mettraux]

On Sat, Jun 15, 2013 at 05:10:37PM -0400, Doug Bryant wrote:
>
> Thank you for the clarification. I didn't realize it was a previous
> version of the workitem. The updated documentation make it clearer.
>
> So if the process_status#workitems returns the workitems as they were at
> the time they were sent *out* to the participants, does the
> process_status#stored_workitems return the workitems that are currently
> *in* the participant?

Hello,

yes. It fetches the workitem from the workitem storage, whereas #workitems
extracts the applied workitem from the expression in the expression storage.

> I just notice the StorageParticipant has a #by_wfid method which seems to
> be a viable way to fetch current workitems by wfid. For this particular
> case of having to update certain workitem fields in a running process, I
> know the wfid ahead of time. I ended up coding it the original way to
> prevent having to keep track of an additional field identifier we use to
> associate workflows with individual records.

OK.

> Seeing now that process_status#workitems returns the workitem as they were
> sent out, from the docs, I would expect #update(workitem) to return true
> indicating the workitem is gone and a newer version available. I never
> figured out why it was erroring out. When you find that issue, please let
> me know. I'm curious as to what it ultimately was.

I've added a note:

https://github.com/jmettraux/ruote/commit/46409dc2bd04d37

The workitem returned by #workitems lacks the type, _id and _rev entries that
would make it a complete "workitem document". When calling update() with
such an incomplete document, the storage stumbles.

This should help (other storage implementations seem to have such a check
already in place):

https://github.com/jmettraux/ruote/commit/2048bc6ad7


Best regards,