Binding issues after transport to production

Thu Feb 12 15:22:10 EST 2009

Mike,

Thanks for this advice.

Given the various things recommended and the fact that all the  
enhancement requests are working in our development environment, I  
think my recommendation to management will be:

1- Clone the 3 workflow templates and retire the the old ones so I am  
pushing up new workflow templates instead of modified workflow  
templates.
2- Set the Persistence Profile to Structure Persistence so that there  
is no ambiguity.

This seems like the best alternative given the amount of work that  
would be involved with converting to XML persistence. Also, it seems  
to me the risk exposure would be fairly minor. If we run into problems  
in production, we can just reactivate the old templates.

Does this seem reasonable?

Carolyn

On Feb 12, 2009, at 12:12 PM, Mike Gambier wrote:

> Carolyn,
>
> When we upgraded a month ago I made sure we kept to the 'old'  
> Persistence Profile approach on all of our Workflow definitions by  
> specifically choosing that option in the version independent tab. I  
> went out of my way to ensure we did not have them switch to the  
> 'Compatability' mode as this was a little ambiguous in its behaviour.
>
> I say ambiguous because I believe if the 'Create' or 'Change'  
> version of the Workflow (I forget which) is somehow updated to be  
> 'more recent' than '640' the system will start to treat it as if it  
> used the XML container approach automatically. I proved this by  
> creating a new version of the WF definition and kicked an instance  
> off and watched as the system automatically classed it as '700' (or  
> whatever version your dev system has) and started to treat it as an  
> XML-based Workflow so updates were going to SWWCNTP0 not SWW_CONTOB.
>
> We also had to implement an OSS Note to ensure that any active  
> Workflow instances switched back to the old binding FMs when we  
> upgraded, but I doubt that applies to you if you upgraded so long ago.
>
> Like you, we have no intention of switching to the XML container for  
> now because of reports and also error handling mechanisms that  
> depend on SWW_CONTOB being properly updated. Trying to parse XML  
> strings and dig through millions of tables entries just doesn't  
> appeal to us!
>
> We've had no problems at all with sending through binding changes  
> from our ECC 6 development system so far though.
>
> Regards,
>
> Mike GT
>
>
> From: fuller at MIT.EDU
> To: sap-wug at MIT.EDU
> Subject: Re: Binding issues after transport to production
> Date: Thu, 12 Feb 2009 11:39:49 -0500
>
> Jocelyn,
>
> When we upgraded to ECC 6.0 a little over a year ago, I did not  
> convert our existing workflow templates to use XML persistence.  
> Therefore their profiles are all set as "Compatibility." I compared  
> our container handling between development  and production via  
> transaction SWU_CONT_PERSISTENCE. But this seems to be used to  
> maintain the outdated "Structure" mode configuration. The table is  
> empty in both environments. Is there another transaction I should  
> run to check container handling?
>
> We have reports that read workflow containers which is one of the  
> reasons I chose not to convert. It is my understanding that  
> converting to XML persistence means I would need to change these  
> reports. Since we weren't experiencing performance or storage  
> concerns I didn't have the incentive to convert. Also, wouldn't I  
> need to change all the business object container operations if we  
> converted?
>
> A lot of these old custom workflow templates created by the non- 
> workflow developer caused us heartaches during our upgrade to ECC  
> 6.0, which is how I discovered some of his unorthodox practices, but  
> they are all working smoothly now.
>
> Carolyn
>
>
> On Feb 11, 2009, at 7:28 PM, Dart, Jocelyn wrote:
>
> Carolyn - just a thought - check in your workflow admin settings that
> both systems are set up with the same container handling (XML) and
> persistency rules.   Also if you aren't already doing this... make  
> sure
> your test scripts for QA always include a test on workflow instances
> that was created and running before your changes were applied.  It can
> be worthwhile deliberately creating workflow instances for this  
> purpose
> before importing your changes into QA.
> Regards,
> Jocelyn
>
> -----Original Message-----
> From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU] On  
> Behalf
> Of Carolyn Fuller
> Sent: Thursday, 12 February 2009 11:05 AM
> To: SAP Workflow Users' Group
> Subject: Re: Binding issues after transport to production
>
> Alon,
>
> Yes. We modified the workflow binding in production in order to fix
> the problems that appeared in production but did not appear in either
> QA or development.
>
> Carolyn
> On Feb 11, 2009, at 4:16 PM, Alon Raskin wrote:
>
> Just to clarify, you are modifying the workflows directly in the
> production system?
>
> Alon Raskin
> e: araskin at 3i-consulting.com
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> Behalf
> Of Carolyn Fuller
> Sent: Wednesday, February 11, 2009 2:17 PM
> To: SAP Workflow Users' Group
> Subject: Binding issues after transport to production
>
> Hi all,
>
> On a couple of occasions I've moved modified workflows from our
> development environment to our QA environment with no problems only to
> encounter binding issues in production. On these occasions, deleting
> the bindings in production and re-creating them in production has
> solved the problem.
>
> Are these issues due to the fact that I didn't run SWU_OBUF after the
> transports went in? Should SWU_OBUF be on our action log when modified
> workflows go into production?
>
> ---
> Carolyn Fuller
> Massachusetts Institute of Technology
> Information Services and Technology
> Administrative Computing
> Senior Analyst/ Programmer
> (617) 253-6213
> http://fuller.mit.edu/
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
>
> Windows Live Hotmail just got better. Find out more!  
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug