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

[Rick Bakker]

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
>