i've a problem with use of "shared object". I've made follows steps:
I've defined a Shared BO (Order) as shown in Kolan guide's
I've instanced the first shared object in main BPM as follow tw.local.mainOrder = new tw.object.Order();
In the same step script I've extract the "key" from the instance in main BPD and i've passed it to other processes (CHILDS) that can work (Read/Write mode) on mainOrder (tw.local.key = tw.local.mainOrder.metadata("key"))
In every "child process" i've referenced shared object as follow tw.local.mainOrder = new tw.object.Order(tw.local.key) where tw.local.key is an ANY object (i tried with string too).
I've no validation error or runtime error, but the when i try to read/write the mainOrder through local reference i failed in attempt (with no error).
By the inspector in every child process i can see the reference to the original object (mainOrder) with the same key ad version.
can you help me?
This topic has been locked.
5 replies Latest Post - 2012-10-10T15:40:40Z by edling
Pinned topic problem with shared object in BPM lombardi V8
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-10-10T15:40:40Z at 2012-10-10T15:40:40Z by edling
Re: problem with shared object in BPM lombardi V82012-10-10T14:15:08Z in response to SystemAdminI'm about to use a similar pattern. I have a shared topObject with a list of subObjects. Each subobject get its own parallel child process instance. Each needs access to the topObject for reading the common information and for editing the instance-specific subObject.
Do you pass your ANY tw.local.key to the child processes via ordinary data mapping?
(I also pass in the index of the subObject to each instance. In my case the index is tw.system.step.counter.)
Re: problem with shared object in BPM lombardi V82012-10-10T15:07:32Z in response to edlingBTW. we are also trying out a contribution/collaboration pattern suggested by our IBM contacts where we create parallel contribution tasks using an UCA. I believe I need the shared object functionality here as well.
However the documentation is confusing:
"Variables that are shared objects
If a variable is defined as a shared object, its values are refreshed from the data store before use. For example, a shared object is passed by value from a BPD to two different services. The BPD and services will each contain a separate copy of the business object. When the first service completes, the values of the shared object will automatically be persisted to the data store. When the second service starts, the shared object values will be automatically loaded from the data store. So even though the BPD and two services reference separate objects, the values of these objects are updated by the data store. This allows the running services to operate on current data. See Creating business objects for information on shared objects."
This does not mention using a shared key as in here:
"You can send data from one process to a second process using a Message Event or by loading the data into the second process using the unique key of the shared business object. To load the data, get the unique identifier key and then load the instance using the key. For example in the following code, sharedBusinessObjectKey would be obtained by running tw.local.myVariable.metadata("key").
tw.local.myVariable = new tw.object.mySharedBusinessObject(sharedBusinessObjectKey);"
One last question is how the parent task/process is "notified" that the shared object has changed in a child task/process. Do I need to regularly poll by some sort of refresh call? (Like save() for the shared object, for comparison.)
SystemAdmin 110000D4XK7615 PostsACCEPTED ANSWER
Re: problem with shared object in BPM lombardi V82012-10-10T15:25:15Z in response to edlingThis is all new functionality in 8.0, so there is a decent chance you are one of the first people using it. I belive the design is intended to be such that the developer does not need to worry about coordinating updates on shared objects, the updates are taken care of for you. Meaning that things like coordinating keys should be handled by the engine. Think of it as being the equivalent of passing an object by refernce in Java/C++ if you do it right (and really meant to do it) then the updates happen without you doing any extra book keeping.
That being said, based on past history there are some use cases I would check before putting my full faith in the shared object code. Here are a few I would test -
If 2 parallel tasks share an object and both can update it, what happens in each of the following scenarios -
- Task A updates and completes and the Task B is started. (Seems like this is called out in the document you quoted, so I would hope it would work).
- Tasks A and B are both started. Task B postpones and Task A completes with an update. When Task B runs again does the data reflect A's update?
- Tasks A and B are both started. Task B closes the browser window instead of postponing. Task A completes with an update. When task B runs, does the data reflect A's update?
- Tasks A and B are both started. When Task B starts, it calls a tw.local.mySharedObject = new tw.object.MySharedType(). Does this change the behavior on any of the above scenarios.
The answers to those will probably cover 90% of the use cases we would care about.
The one that your business users probably will be most grumpy about is that I believe the operation is "last write wins". So on a system where 2 users submit very close in time, the result may appear wrong to one of those users.
Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
Re: problem with shared object in BPM lombardi V82012-10-10T15:33:27Z in response to edlingStupid me. The answer to my last question is of course the code line above it.
We do a system of record retrieval at every resume after a postpone, but on top of this a load and a diff would probably be needed before every save as an implementation of optimistic concurrency.
Re: problem with shared object in BPM lombardi V82012-10-10T15:40:40Z in response to edlingActually, we might not even want to use a shared object as soon as we get out SOR working. Now I should call it a day and reflect, instead of spamming this thread. (17.42 CET)