Interesting issue arising from changing a workflow key after the workflow has started

[Rick Bakker]

Hi James,

Yes, that is correct. You should be able to see these old values when
you look at the workflow log and when you use SAP_WAPI_READ_CONTAINER.
It's very possible that the values are stored elsewhere as well. See
how it goes.

regards
Rick

On Fri, Mar 30, 2012 at 10:25 PM, James Johnson <JJOHNSON at uk.ibm.com> wrote:
> Hi Rick,
>
> I think this is where my workflow (lack of) knowledge is shown up - are you
> saying that when the workflow executes a work item, the workflow key used is
> in the XML container (SWWCNTP0)?  If so this explains what's going on, and
> why our amendments haven't worked.  And if this is the case, I think there's
> a potential solution in the form of using a FM such as
> SAP_WAPI_READ_CONTAINER and SAP_WAPI_WRITE_CONTAINER to check/amend the
> object key for each workflow of the type that's been affected, which should
> have the knock on effect of causing the container values to be updated.
>
> Best Regards,
> James Johnson
>
>
> E-mail:JJohnson at uk.ibm.com
> Mobile: 07908715224 or 07920870270
>
>
> -----sap-wug-bounces at mit.edu wrote: -----
>
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> From: Rick Bakker
> Sent by: sap-wug-bounces at mit.edu
> Date: 03/30/2012 11:32AM
> Subject: Re: Interesting issue arising from changing a workflow key after
> the workflow has started
>
>
> Hi James,
>
> This may seem a bit obvious but surely the old key is also stored in
> the workflow container?
> You did say this was for existing workflows. One of the relevant
> tables is SWWCONTP0.
> Changing that will be very difficult. I assume you know that changing
> data in tables is truly a last resort.
>
> regards
> Rick Bakker
> hanabi technology
>
> On Fri, Mar 30, 2012 at 9:00 PM, James Johnson <JJOHNSON at uk.ibm.com> wrote:
>> Dear experts,
>>
>> I have an interesting situation, and a curious issue which I can't seem to
>> find the cause of.  I am working on a utilities project and experienced an
>> inital issue where particular workflows to change a customer's meter type
>> were created with duplicate keys.  We have now amended the key for the
>> workflow to be unique, and this seems to have fixed the issue for new
>> workflows which are being created.  Essentially, the previous key was a
>> customer's contract account number (12 characters), followed by a contract
>> account start date (8 characters).  A customer could have a type of
>> account
>> where both their gas/electricity had the same contract account number (but
>> individual contract numbers under the same contract account), which led to
>> the duplicate keys (and subsequent container data issues).  The new key is
>> a
>> contract account (12 characters), contract (10 characters), and division
>> (2
>> characters, either 10 for electricity or 20 for gas).
>>
>> The curious issue that has now manifested itself is due to us needing to
>> also consider old workflows previously operating under the old key which
>> are
>> still active in the system.  We tried to account for this by writing a
>> program to update all relevant values of INSTID in table SWW_WI2OBJ, in
>> addition to amending all relevant entries of the OBJKEY field in table
>> SWFDEVINST.  The entries have now all been updated, however we have now
>> observed an unfortunate side-effect of the update.  The value for the
>> contract in the workflow container (which is supposed to be characters 13
>> to
>> 22 of the new key), is now populated by the old key's contract account
>> start
>> date (which by no co-incidence used to be occupied by the contract account
>> start date in the old key format).  This then means that the old workflows
>> fall over once they reach a step that requires them to use the contract
>> (all
>> of them in fact).
>>
>> I think the relevant question to the group here is whether there is
>> anywhere
>> else the workflow engine could be storing/retrieving the key from that is
>> being referenced/used to construct the object during operation, as it
>> appears that even though the key has been amended to the new one, the old
>> one is still persisting somewhere for it to be used by the workflow.
>> Hopefully the above information is enough to go on, I've avoided listing
>> the
>> technical details of what i've coded the constructor/super class
>> constructor
>> to do to avoid creating more detail than may be necessary, but I'm quite
>> happy to list anymore information that might help resolve this interesting
>> issue.
>>
>> Best Regards,
>> James Johnson
>> IBM
>>
>> E-mail:JJohnson at uk.ibm.com
>> Mobile: 07908715224 or 07920870270
>>
>>
>> ________________________________
>>
>>
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
>
> ________________________________
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>