".pxInsName: Keys of Instance Value must be specified" when executing pyStartCase via SOAP
Hi,
I've got a problem running a simple soap-call against a service which uses pyStartCase to start a certain case.
If there is no assignment-shape between the start-shape and a utility-shape (which should perform a pxMove) the soap-call fails with the error message:
".pxInsName: Keys of Instance Value must be specified".
If I put a assignment-shape in between the start- and utitlity-shape everything works as expected.
Same happens, when I call the Flow within the case in PRPC with "Run".
The error message is:"Key:Keys of Instance Value must be specified"
If I look into the clipboard "pyWorkPage" is empty and marked red - the Tracer gives me some errors like "The Record is stale."
Any hint or help is really appreciated, since i've working on this more than 2 days right now.
Kind regards,
kw
Accepted Solution
Pegasystems
DE
I had a short look at pxMove. Looking at its usage, it is not designed to be used for a newly created object
The API handles the scenarios when it is called from child case or old cover case.
It is not intended be called from new cover case.
However, I could achieve the intended behaviour with three steps in a custom activity
1. Obj-Open-By-Handle (of the to-be-parent) with params
- the instance handle
- Lock and ReleaseOnCommit checked
2. Call AddToCover (for the to-be-parent) with params
- workPage=pyWorkPage
3. Call RecalculateAndSave (for the to-be-parent; to satisfy bookkeeping) with params
- updatePage="SystemUpdate:"+Primary.pyID+":Added:"+Primary.pxObjClass
The last argument is stolen from another call (At quick glance it is not well described). You can also deduce it by looking at the called activity.
Wrt use case:
I think this is a valid use case, where the payload of the newly created WO has enough info to deduce the to-be-parent.
(One could argue that in this case, you might call a service at the parent instead, which adds the new child or a custom service activity which does it explicitly).
But in principal there could be an OOTB activity that does this.
There might be a better alternative though.
Anyone anything?
Frontier BPM
US
Not sure if this is relevant to you but couple of days back faced similar issue.
We had following steps in activity where in it creates the WO after reading data from a file.
Page-New tempPage
Property-Set tempPage
Obj-Save tempPage
Call svcAddWorkObject tempPage
in the above steps, when commented the obj-save step, it was throwing an error with the same message. having obj-save resolved the issue for us.
Regards,
Burhan.
Updated: 7 Oct 2015 19:24 EDT
Pegasystems Inc.
JP
Which version of PRPC are you working on?
I think the work object has not been saved in to DB yet when the soap activity being called.
Adding assignment shape between the start shape and the utility shape will cause the work object be saved when the flow reach the assignment.
Updated: 8 Oct 2015 3:16 EDT
Allianz Deutschland AG
DE
Thanks for all your replies!
Chunzhi Hong I'm using 7.1.9 and also tried a "Persist Case"-Shape which did not help (also pxUpdate, pxSaveCase, pxCommit, aso.) - since I can't wait for a user/system to perform the assignment (I also tried auto-perform with "Always") this is not feasible for me. I have a workaround by using the integration-assignment which is waiting for another soap-call, so I end up with 3 soap-calls (start,wait,wait).
Joel Mcleish I tried that also and it worked, but I also consider that as a workaround and it might start some discussions about "why is this necessary". At least a "Persist Case"-Shape should do the trick imho.
Mohammed Burhanuddin Sorry that did not worked - I got a tempPage with the correct class and everything but my pyWorkPage is messed up anyway.
Thanks for all your replies!
Chunzhi Hong I'm using 7.1.9 and also tried a "Persist Case"-Shape which did not help (also pxUpdate, pxSaveCase, pxCommit, aso.) - since I can't wait for a user/system to perform the assignment (I also tried auto-perform with "Always") this is not feasible for me. I have a workaround by using the integration-assignment which is waiting for another soap-call, so I end up with 3 soap-calls (start,wait,wait).
Joel Mcleish I tried that also and it worked, but I also consider that as a workaround and it might start some discussions about "why is this necessary". At least a "Persist Case"-Shape should do the trick imho.
Mohammed Burhanuddin Sorry that did not worked - I got a tempPage with the correct class and everything but my pyWorkPage is messed up anyway.
This "bug" is really easy to spot, if you try to do a pxMove in between a assignment-shape and the start-shape. I would consider that as a standard use-case for attaching cases to another cases without any user-interaction.
Pegasystems Inc.
AU
Hey Kai,
My understanding is the persist shape is to make a temporary work object permanent.
The wait shape is a necessary evil I've found in instances where there's no user interaction before any straight through processing as an 'assignment' of some sort is required to make the first commit and calculate the inskey et al.
Frontier BPM
US
We had given the
Call svcAddWorkObject tempPage
flowType ="pyStartCase"
organization="your Org.com"
workpage="pyWorkPage"
as params.
This should do as we have used this many a times in various other projects also.
We have used this in 6.2 as well as 717.
Regards,
Burhan.
Pegasystems
DE
Kai, you should not call pyStartCase directly from a SOAP service.
The Service Wizard can be used to generate the wrapper for svcAddWorkObject, which is the main activity to create a case from an inbound service call.
All data from the temp clipboard page can be mapped into the new object, if needed.
If you have other tasks to do, e.g. create a case _and_ upload/associate a document to it in one shot, I normally create a wrapper activity for svcAddWorkObject and do the rest in a few other steps.
Hth,
Andreas
Accepted Solution
Pegasystems
DE
I had a short look at pxMove. Looking at its usage, it is not designed to be used for a newly created object
The API handles the scenarios when it is called from child case or old cover case.
It is not intended be called from new cover case.
However, I could achieve the intended behaviour with three steps in a custom activity
1. Obj-Open-By-Handle (of the to-be-parent) with params
- the instance handle
- Lock and ReleaseOnCommit checked
2. Call AddToCover (for the to-be-parent) with params
- workPage=pyWorkPage
3. Call RecalculateAndSave (for the to-be-parent; to satisfy bookkeeping) with params
- updatePage="SystemUpdate:"+Primary.pyID+":Added:"+Primary.pxObjClass
The last argument is stolen from another call (At quick glance it is not well described). You can also deduce it by looking at the called activity.
Wrt use case:
I think this is a valid use case, where the payload of the newly created WO has enough info to deduce the to-be-parent.
(One could argue that in this case, you might call a service at the parent instead, which adds the new child or a custom service activity which does it explicitly).
But in principal there could be an OOTB activity that does this.
There might be a better alternative though.
Anyone anything?