SAP-WUG Digest, Vol 80, Issue 27
Volker Wegert
sap-wug at volker-wegert.de
Tue Nov 1 02:25:53 EDT 2011
<delurk>
Nandakumar,
initialization should usually happen within the constructor. Just one word of caution - be careful when redefining methods that are called from the constructor. I wrote a bit about this back in March: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/23738
Regards
Volker
</delurk>
Am 30.10.2011 um 14:14 schrieb Nandakumar Alavandar:
> Hi Jocelyn,
>
> We have almost completed the workflows for creating the sales process from the Interface data received through the staging table, the approach I have taken is as below.
>
> ZCL_ROOT_WF - Root class method 'BI_PERSISTENT~FIND_BY_LPOR', 'CONSTRUCTOR' is declared .
> ^
> ZCL_MAIN_CLASS_WF- Root as super class, Staging Table attributes Header and Item , Events are only triggered from this class.
> ^
> ZCL_SALESORDER_WF - Main class as super class, and staging table attributes are used to create orders.
>
> I need a clarification in my root class -BI_PERSISTENT~FIND_BY_LPOR method,
> In this method I create instance for the object with reference and in same method I call the initialize method(main class) where I initialize my attributes for my staging table.
>
> Can you please advise me whether the initialize method(Main class) being called in 'BI_PERSISTENT~FIND_BY_LPOR,' would create any issues or better to call it in the constructor ( I pass only the object key and typeid of the class to keep constructor lean).
>
> METHOD bi_persistent~find_by_lpor.
> DATA: l_object TYPE REF TO zcl_root_wf.
> DATA: l_class_name TYPE seoclsname.
> DATA: l_objkey TYPE sibflpor-instid.
>
>
> *- instid is the key of the object
> l_objkey = lpor-instid.
> l_class = lpor-typeid.
>
> TRY.
> l_class_name = l_class.
> CREATE OBJECT l_object
> TYPE
> (l_class)
> EXPORTING
> object_key = l_objkey
> class_type = l_class_name.
>
> CALL METHOD l_object->initialize
> EXPORTING
> object_key = l_objkey.
>
> CATCH cx_bo_error .
> *------ object not found
> EXIT.
> ENDTRY.
>
> result = l_object.
>
> ENDMETHOD.
>
>
> Regards
> Nandakumar
> From: Nandakumar Alavandar <nanda_kumar1 at yahoo.com.au>
> To: "sap-wug at mit.edu" <sap-wug at mit.edu>
> Sent: Wednesday, 27 July 2011 9:01 PM
> Subject: Re: SAP-WUG Digest, Vol 80, Issue 27
>
> Hi Jocelyn,
>
> Thanks for your time and valuable inputs, all my previous developments are based on the approval automation after creation of the documents, first time I am coming across the creation of documents for a huge process in workflow.
>
> I will take consideration of the below inputs while developing and configuring the event queue, I am quite confident now when I hear it from the workflow 'GURU'.
>
> Thanks & Regards
> Nandakumar
>
> From: "sap-wug-request at mit.edu" <sap-wug-request at mit.edu>
> To: sap-wug at mit.edu
> Sent: Tuesday, 26 July 2011 11:24 PM
> Subject: SAP-WUG Digest, Vol 80, Issue 27
>
> Send SAP-WUG mailing list submissions to
> sap-wug at mit.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.mit.edu/mailman/listinfo/sap-wug
> or, via email, send a message with subject or body 'help' to
> sap-wug-request at mit.edu
>
> You can reach the person managing the list at
> sap-wug-owner at mit.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of SAP-WUG digest..."
>
>
> Today's Topics:
>
> 1. RE: Suggestion required for creating sales process through
> workflow (Dart, Jocelyn)
> 2. Have authority checks disappeared from WAPIs? (Mike Pokraka)
> 3. RE: Have authority checks disappeared from WAPIs? (Mike Gambier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 Jul 2011 04:14:35 +0200
> From: "Dart, Jocelyn" <jocelyn.dart at sap.com>
> Subject: RE: Suggestion required for creating sales process through
> workflow
> To: "SAP Workflow Users' Group" <sap-wug at mit.edu>
> Message-ID:
> <8C507B5E0BA5114E933C3C6E2E9729E0075B5AEEED at DEWDFECCR01.wdf.sap.corp>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Nanda,
>
>
> 1) Nothing wrong with using CX_BO_TEMPORARY as a permanent solution ... although you might want to adjust the number of retries as well. Particularly if you are using the event queue to help spread the load.
>
> 2) That's what the Event Queue is for.
>
> 3) That's not an issue it's a description of the business scenario.
>
> 4) The point of the event queue is to drip feed the events into the system to AVOID system performance issues caused by too many events hitting the system at one time.
>
> The numbers you are talking about 100s are actually fairly small volumes for workflow. Event queue should be enough for 100s and even 1000s.
> But your stress test should include monitoring and if necessary adjusting the event queue parameters for read accesses and intervals - start with the standard and work from there.
> Regards,
> Jocelyn
>
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Nandakumar Alavandar
> Sent: Saturday, 23 July 2011 7:50 PM
> To: sap-wug at mit.edu
> Subject: Suggestion required for creating sales process through workflow
>
> Hi,
>
> I have a specfic requirement to implement sales process worklow for my client .
> Requirement:
> The entire sales process starting from Sales order to Shipment cost is already completed in the legacy system, and the data is later send to Process Interface as a flat file to update the staging table in SAP through proxy.
> The data recieved is for the previous day transactions, in few region records can be send every 20 minutes instantly from the legacy sytem to SAP .
>
> The client is interested in doing the entire process of creation sales order to shipment process using the workflow , advantage the client thinks is the tracking process.
>
> Issues Identified -
> 1) Locking issues while creating sales orders for the same contract.(there could be 400 sales order created in the same day and contract ),the CX_BO_TEMPORARY to handle the temporary locking issue but not a permant solution.
> 2) Huge volume of workflow events will be triggered in a short duration of time,
> 3) Each workflow instance triggered will be involved in creation of sales order to shipment cost prcoess.
> 4) Activated the event queue which distributes the load, but system performance could be affected.
>
> Alternative solution proposed to do the entire process in schedule batch program and handle the error scenario through workflow .
>
> Suggestion required whether the above process could be efficient through the workflow process for high voume data.
>
> --
> Warm Regards
> Nanda kumar
> SAP-Workflow Consultant.
> Mobile: +61432070354<tel:%2B61432070354>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110726/2a9bea2d/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Jul 2011 11:46:14 +0100 (BST)
> From: "Mike Pokraka" <wug at workflowconnections.com>
> Subject: Have authority checks disappeared from WAPIs?
> To: sap-wug at mit.edu
> Message-ID:
> <154b410a72d99e8c754a44f3f4e9fe33.squirrel at g.mail.aaisp.net.uk>
> Content-Type: text/plain;charset=iso-8859-1
>
> G'Day,
>
> I'm not sure if I've just noticed this or if it's been this way for a
> while, or if my memory is deceiving me:
>
> One upon a time the WAPIs used to be a formal wrapper for the equivalent
> SWF*/SWW* function modules. I think the WAPIs used to do indirect auth
> checks via these FM calls, however since the FMs can be overriden (e.g. FM
> SWW_WI_ADMIN_CANCEL has a parameter AUTHORIZATION_CHECKED) I am not too
> sure and have no 4.6 system handy to check.
>
> Nowadays (ECC6) however, the WAPIs use OO methods internally and as far as
> I have been able to establish there are no auth checks carried out - if a
> user can execute FM SAP_WAPI_ADM_WORKFLOW_CANCEL by any means then they
> can cancel a work item. Unfortunately I haven't been able to conclusively
> test this with a user that has SE37 but no workitem admin access, but
> debugging shows no auth check.
>
> Could someone verify I've got this right? Has this changed? Am I just
> confused?
>
> I'm going to implement my own auth checks anyway, but I am very curious as
> it *may* mean that custom code written pre-ECC could have turned into a
> security hole post-upgrade.
>
> Regards,
> Mike
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 26 Jul 2011 13:24:05 +0000
> From: Mike Gambier <madgambler at hotmail.com>
> Subject: RE: Have authority checks disappeared from WAPIs?
> To: <sap-wug at mit.edu>
> Message-ID: <SNT107-W629B232CC9C1AF11E3AFC6D5320 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Mike,
>
> Did you check that a call to CL_SWF_RUN_WIM_LOCAL->IF_SWF_RUN_WIM_UTL_INTERNAL~CHECK_AUTHORITY is NOT being executed?
>
> I thought it would always be invoked, regardless of whether a WAPI is invoking the Workflow stuff.
>
> Normally the ABAP OO Exception CX_SWF_RUN_WIM_AUTH_FAILED will be thrown I think.
>
> Mike GT
>
>
> > Date: Tue, 26 Jul 2011 11:46:14 +0100
> > Subject: Have authority checks disappeared from WAPIs?
> > From: wug at workflowconnections.com
> > To: sap-wug at mit.edu
> >
> > G'Day,
> >
> > I'm not sure if I've just noticed this or if it's been this way for a
> > while, or if my memory is deceiving me:
> >
> > One upon a time the WAPIs used to be a formal wrapper for the equivalent
> > SWF*/SWW* function modules. I think the WAPIs used to do indirect auth
> > checks via these FM calls, however since the FMs can be overriden (e.g. FM
> > SWW_WI_ADMIN_CANCEL has a parameter AUTHORIZATION_CHECKED) I am not too
> > sure and have no 4.6 system handy to check.
> >
> > Nowadays (ECC6) however, the WAPIs use OO methods internally and as far as
> > I have been able to establish there are no auth checks carried out - if a
> > user can execute FM SAP_WAPI_ADM_WORKFLOW_CANCEL by any means then they
> > can cancel a work item. Unfortunately I haven't been able to conclusively
> > test this with a user that has SE37 but no workitem admin access, but
> > debugging shows no auth check.
> >
> > Could someone verify I've got this right? Has this changed? Am I just
> > confused?
> >
> > I'm going to implement my own auth checks anyway, but I am very curious as
> > it *may* mean that custom code written pre-ECC could have turned into a
> > security hole post-upgrade.
> >
> > Regards,
> > Mike
> >
> > _______________________________________________
> > 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/20110726/7a67b639/attachment.htm
>
> ------------------------------
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>
>
> End of SAP-WUG Digest, Vol 80, Issue 27
> ***************************************
>
>
>
>
> _______________________________________________
> 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/20111101/5fc48437/attachment.htm
More information about the SAP-WUG
mailing list