Deep Structures in container

Wed Apr 27 13:22:30 EDT 2011

Hi  Kjetil/Mike/Jocelyn

thanks for your points, I appreciate your feedback.

Unfortunately I come to this project too late to impart the change I would like and some of your fine suggestions. So for now I am governed by the "legitimate but annoying reasons".

So our approach (which is OO class based) will be to store the material data in the contrainer. Data is captured in 'stagegates' not all at once, so this minimises the size issue. Also I've done analysis of SWWCNTP0 which is looking manageable (I've added comments to a recent blog on this subject by Eddie Morris SAP)
https://weblogs.sdn.sap.com/pub/wlg/24176

If this approach causes  problems, I like the suggestions mentioned before ie XML serialising or the table deep struc. 

Mike regarding the option of storing the data in a table with a deep struc, I didn't think it was possible to store a deep structure in a database table, only internally in local tables.? Am I missing something?

Mark

> Date: Tue, 26 Apr 2011 09:50:07 +0200
> From: Kjetil Kilhavn <kjetil.kilhavn at bluec.no>
> Subject: Re: Deep Structures in container
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Message-ID: <201104260950.07773.kjetil.kilhavn at bluec.no>
> Content-Type: Text/Plain; charset="iso-8859-1"
> 
> Tirsdag 19. april 2011 18.59.07 skrev Mike Pokraka :
> > Hi Mark,
> > 
> > Technically it's possible - if not ideal- but practically I don't see the
> > value in it. There are plenty of alternatives to prevent a material from
> > being used during creation. Plant/Material status fields are easy
> > candidates. The advantage of doing it all directly on the material is that
> > you have the entire history of who added what and when as opposed to a big
> > pile of data created by a system user.
> I couldn't agree more. The value of change logs is often not seen until a 
> question comes from senior management who demands to know who made or changed 
> a document and you're not able to answer the question because change logs have 
> been falsified (UPDATE cdhdr, I have only seen this once luckily) or are not 
> used as pointed out by Mike.
> 
> The only time I have seen a value in storing much data in the container is 
> when the data can be changed and the user must see the data exactly as they 
> were when the workflow was started. This is rarely a requirement from the 
> customer, but it has occurred in one case (during my 10 years).
> 
> > More importantly, as you are already aware materials are complex, and
> > you're throwing any config-based validations and consistency controls out
> > of the window when you create a temporary storage concept. You either need
> > to duplicate this in all your input dialogs, or are headed for some
> > serious exception handling at posting stage.
> Or quite simple, but very user-hostile exception handling, as in: the update 
> failed - please start over from scratch :-)
> -- 
> Kjetil Kilhavn (+47 40220607)
> Blue Consulting AS (http://www.bluec.no)
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 26 Apr 2011 15:09:01 +0100 (BST)
> From: "Mike Pokraka" <wug at workflowconnections.com>
> Subject: RE: Deep Structures in container
> To: "SAP Workflow Users' Group" <sap-wug at MIT.EDU>
> Message-ID:
> <32b818ca985bab1f7b10f848ce97e1cf.squirrel at g.mail.aaisp.net.uk>
> Content-Type: text/plain;charset=iso-8859-1
> 
> 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
> >
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 26 Apr 2011 17:05:30 +0100
> From: "Vijayendra Rao (Absoft)" <vrao at absoft.co.uk>
> Subject: RE: UWL Replace option or Replace button
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Message-ID: <2C9B4CD8BAE97847924AF9B2233248C701C82C4F at ABSM01>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
> 
> 
> 
> The current PO approval workflow may potentially be sent to more than
> one person so if one person goes into the approval workflow they are
> effectively starting the process - if they back out of it as they decide
> the PO is not for them to approve this means that the workflow is no
> longer available for any other approver to action.
> 
> 
> 
> Is there anything that we can do so that the workflow remains available
> to the approvers until the PO is either approved or rejected?
> 
> 
> 
> In SBWP the users have 2 choices 
> 
> 1). To forward the workitem to the actual approver using the forwarding
> option
> 
> 2). Choose the replace option to convert the workitem from status in
> process to status new.
> 
> 
> 
> In UWL.
> 
> Currently we have only the Forward option and the users feel it is quite
> difficult to forward it as the UI to forward in UWL is not that easy. 
> 
> 
> 
> In our UWL we don't have the Replace option or Replace button. Any idea
> how to enable this button in UWL? 
> 
> 
> 
> Thanks
> 
> VJ
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110426/dc227de9/attachment-0001.htm
> 
> ------------------------------
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> 
> End of SAP-WUG Digest, Vol 77, Issue 43
> ***************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110427/d5ad24b3/attachment.htm