Deep Structures in container

Tue Apr 26 20:55:49 EDT 2011

Hi Mark, 

Just a thought ... but have you taken a look at how "Master Data Governance" works??? 
This is a newish business function for ECC 6.0 EHPs ... essentially does something like your scenario - and yes it uses its own tables. Worth taking a look at their approach at least - try the help.sap.com doco for starters. 

Material Master also has "planned changes" (check the menus in MM01/2/3)- which might give you an alternative to creating your own custom tables. 

But I don't think anyone's going to ok storing that amount of data in the workflow container for a volume scenario such as material master changes.  Apart from the performance considerations, what's going to happen when your customer then asks to e.g. get a list of all materials with attribute x value y and where they are at in the workflow?   With custom tables you can report on it easily. With deep-structure containers any sort of auditing or analytics would become very painful. 

Regards,
Jocelyn 

-----Original Message-----
From: sap-wug-bounces at MIT.EDU [mailto:sap-wug-bounces at MIT.EDU] On Behalf Of Mike Pokraka
Sent: Wednesday, 27 April 2011 12:09 AM
To: SAP Workflow Users' Group
Subject: RE: Deep Structures in container

Hi Mark,

Kjetil has a good points, and from personal experience I'd still not
recommmend it but then again I've also had to do it before due to
"legitimate but annoying reasons" :-)

I would go with Paul's earlier suggestion and store the data in one or
more custom tables. In workflow you can have a 'Temp material' object
keyed on this table/s (as you're starting from scratch I'd definitely
recommend OO over BOR here). You can either use a single table with a deep
structure, or serialize your data into XML, or have a set of tables
mirroring the MA* tables. All have their dis/advantages and I'm sure you
can work out what suits your cause.

Cheers,
Mike

On Thu, April 21, 2011 12:09 pm, Mark Daley wrote:
>
> 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
>  		 	   		  _______________________________________________
> 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