Deep Structures in container

[Mark Daley]

Hi Paul/Mike
 
thanks for your replies, sorry for the delay getting back, we've been discussing this internally.
 
I agree with you both that storing outside of workflow on either SAP or custom tables is the best approach. 
 
Storing the data in SAP Master Data and using statuses is an obvious way to go, but it not an option here for legitimate but annoying reasons I won't go into.
Storing in Z tables, is too complex as it will effectively mean replicating SAP Material Master.
 
So we're are going to take approach of storing in the deep struc in the container. I've done some anaylysis of SWWCNTP0
I did a simple test with a container with 1 basic element, it takes up approc 1 line (1024 chars). My deep struc unfilled takes up 3,700chars, and filled takes up 10,000chars.
 
Is this alot of space for a WF container are there any guidlines on this? Or is it all down to system size etc.
 
I've read that if this table gets too large there could be performance issues, so our intention is that in PRD we'll just have to archive more frequently. 
 
Is this the main potential impact on performance or could there be others associated with passing alot of data between containers?
 
Would like to hear your experience.
 
Mark
 
 
> Subject: Re: Deep Structures in container
> To: sap-wug at mit.edu
> From: Paul.Bakker at osr.treasury.qld.gov.au
> Date: Tue, 19 Apr 2011 08:06:12 +1000
> 
> Mark,
> 
> Your approach sounds a lot like the workflow 'forms' concept, where a form
> full of data is passed to various users for completion (and approval), and
> is then committed to the database. But I think 'forms' can only handle flat
> structures.
> 
> Generally it is not best practice to pass large amounts of data in a
> workflow. Imagine how the container database table would blow out in size,
> if the data was replicated for each workitem..!
> Instead, pass a unique key to the data.
> 
> So in this case, you could store all this to-be-approved Material data in a
> custom (nested) database table. The table could have a GUID key, which the
> workflow can refer to.
> 
> Or.. does Material Management have the concept of a 'parked' material, that
> can be stored in standard tables, pending approval?
> 
> cheers
> Paul Bakker
> 
> 
> 
> From: Mark Daley <mark_daley at hotmail.com>
> To: <sap-wug at mit.edu>
> Date: 18/04/2011 10:59 PM
> Subject: Deep Structures in container
> Sent by: sap-wug-bounces at mit.edu
> 
> 
> 
> 
> Hello folks,
> 
> I am building a Material Master Data Request workflow (ECC 5.0) and I would
> like your input on storing large amounts of data in deep structures in the
> workflow container.
> 
> The business requirement is to gather the material data from several agents
> concurrently/parallel(via custom screens) and once all tasks are completed
> the Material request is sent for approval. If all is well the data is
> posted to SAP (via BAPI). Each agent enters unique data pertaining to their
> role in the business eg R&D, Finance etc.
> 
> In the workflow, I am storing this data in a single container element(deep
> structure) containing 18 sub structures eg MARA, MARC etc and 9 tables eg
> MAKT , MARM etc.
> 
> The intention of using a single deep structure is to reduce maintenance on
> the number of wf bindings. The interface to the FM that calls the various
> custom screens uses this same deep structure.
> 
> Could passing a large deep structure data element between task and wf cause
> issues eg performance/storage/archiving? There will be approx 2000
> workflows a month.
> 
> Given the data gathered from the agents must be approved before being
> posted in SAP, is there any other way I could be doing this other than
> using a deep structure to store the data in the workflow?
> I don’t want to explicitly add a data element for each piece of material
> data in my wf container plus all the bindings!
> 
> I’d appreciate your input/experience especially if you have any experience
> of workflow handling large amounts of data in the container or with deep
> structures.
> 
> Thanks
> Mark_______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> *********************************************************************************************
> Only an individual or entity who is intended to be a recipient of this e-mail may access or use the information contained in this e-mail or any of its attachments. Opinions contained in this e-mail or any of its attachments do not necessarily reflect the opinions of Queensland Treasury.
> 
> The contents of this e-mail and any attachments are confidential and may be legally privileged and the subject of copyright. If you have received this e-mail in error, please notify Queensland Treasury immediately and erase all copies of the e-mail and the attachments. Queensland Treasury uses virus scanning software. However, it is not liable for viruses present in this e-mail or in any attachment. 
> ***************************************************************************************************
> 
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110421/da1e9803/attachment.htm