Shopping Carts

Ramki Maley rmaley at erpworkflow.com
Fri Jun 3 09:58:10 EDT 2011 

Dale, thanks for the update and good to hear that the problem is 
resolved. I could be wrong but as far as I know, there is no way to turn 
off the log for BRF. It is the first place to check when something is 
not working in the SRM BRF. If the event/expression did not transport 
properly, I would think creating a new event and adjusting the process 
schema would be a better option than making changes in the target systems.

Regards,
Ramki.


On 6/3/11 8:19 AM, Dale Brown wrote:
> Thanks all for the feedback (Ramki, Thomas, and Rick).
>
> Ramki - We did not check the log (SLG1) because we have since found out another problem with the application log entries. It seems that our shopping cart entries have not been going to this table (BALHDR) in our production and pre-production systems for the past two months.  Trying to find out if something has been applied to those systems or somebody has turned of logging that may have caused this.  Is there a way that a user could configue that you don't want logging as that seems in SPRO that there are some config items?  Entries are still working correctly to the log in our development system.
>
> Thomas - The things you suggested we had checked as all config seemed to have been transported correctly as well as workbench development.  Tasks were generalized as well. This is for a fully rejected cart.
>
> Rick - yes
>
> Here's what we have found but don't know exactly why things behaved this way.
> Prior to sending my original email to the MIT group - we checked everything to see if all transported ok.  We found that our custom rejected event did not make it up to the other system.  So we did a new transport and then it went up ok.  We then found out that the custon rejected expression called by the rejected event was missing the formula.  So we tried to do a new transport for that as well, but the  formula was still missing up on the other system.  We had basis unlock the system we transported to and they keyed in the formula. This still did not fix the problem, and this is when I sent the email out to the group.  We did run BRF_TRANSPORT_SIMPLE back when our development system was set up, but the user had previously decided not to run it up on the other system when it was built.  So we have now run BRF_TRANSPORT_SIMPLE up on our pre-production system. That still did not fix our problem. We have since discovered in our reject event that we set up that the entries in t!
>   he determine-assignment classes were missing (CL_DET_ASSIGNMNT_RL_BRF and CL_DET_ASSIGNMNT_RS_BRF) at least they were not being displayed.  So we did another transport from development to see if that would fix this problem.  Still could not see these entries.  So we had basis unlock the system again and when they went in they could see these entries already there, but they were prompted to do a save.  Once they saved this, we can now see the entries and the rejection workflow is working correctly now.  We have been in production for a few months now and all previous transports for our custom events and expressions transported without any issues.  Not sure why these inconsistencies for the rejected event and expression occurred.   If any of you have any theories - please share.
>
> Thanks again for all the response.
>
> Dale R. Brown
> DUKE UNIVERSITY
> Sr. Analyst, IT
> OIT - Application and Database Services
> 919.684.5341
>
>
> -----Original Message-----
> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of sap-wug-request at mit.edu
> Sent: Thursday, June 02, 2011 6:20 PM
> To: sap-wug at mit.edu
> Subject: SAP-WUG Digest, Vol 79, Issue 6
>
> 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: SAP_ALL SAP_NEW (Edward Diehl)
>     2. RE: SAP_ALL SAP_NEW (Edward Diehl)
>     3. Re: Shopping Cart Rejections (Rick Bakker)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 Jun 2011 15:18:41 -0500
> From: Edward Diehl<edwarddiehl at hotmail.com>
> Subject: RE: SAP_ALL SAP_NEW
> To:<sap-wug at mit.edu>
> Message-ID:<COL104-W192FD1D0ED4DA7F8E6155BA27C0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Whenever we assign SAP_ALL and SAP_NEW to WF-BATCH, everything works just fine.  We are being told that we cannot use SAP_ALL&  SAP_NEW.  We tell them WF-BATCH is NOT a user like others, etc.
>
> Is anyone successfully running workflows in a production environment where WF-BATCH has some other security role(s) other than SAP_ALL&  SAP_NEW.  If you are I sure would like to know how.
>
> Thanks,
> Ed
>
> CC: sap-wug at mit.edu
> From: madgambler at hotmail.com
> Subject: Re: SAP_ALL SAP_NEW
> Date: Thu, 2 Jun 2011 20:59:22 +0100
> To: sap-wug at mit.edu
>
> Presumably you have tried regenerating SAP_ALL in the target system?
> Worth a mention just in case somebody forgot?
> Mike GT
>
> Sent from my iPhone
> On 2 Jun 2011, at 20:41, Edward Diehl<edwarddiehl at hotmail.com>  wrote:
>
>
> Thanks, Eddie, but therein lies the problem.  We've applied the note and we are still left with tasks failing because of no-authorization - and these failed to show up on the Security's authorization trace.
>
> As I asked, is anyone out there successfully using workflow where WF-BATCH does not have SAP_ALL AND SAP_NEW?
>
> Ed
>
> From: eddie.morris at sap.com
> To: sap-wug at mit.edu
> Date: Thu, 2 Jun 2011 20:54:19 +0200
> Subject: RE: SAP_ALL SAP_NEW
>
>
>
> Hi Ed, Take a look at note 1251255 which introduces SAP_BC_BMT_WFM_SERV_USER. It takes care of the authorization for the workflow runtime but you still need to add application specific authorizations. KBA 1574002 also gives details. Regards,Eddie From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Edward Diehl
> Sent: 02 June 2011 19:33
> To: sap-wug at mit.edu
> Subject: RE: SAP_ALL SAP_NEW Is anyone out there successfully using workflow with WF-BATCH carrying something other than SAP_ALL&  SAP_NEW security roles?
>
> I'm sure many of you have confronted this issue.  I would be interested to hear your experience(s).
>
> Thanks,
> Ed
> _______________________________________________
> 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 		 	   		
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110602/248a6eaf/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Thu, 2 Jun 2011 15:23:22 -0500
> From: Edward Diehl<edwarddiehl at hotmail.com>
> Subject: RE: SAP_ALL SAP_NEW
> To:<sap-wug at mit.edu>
> Message-ID:<COL104-W5FE67B364A25AA96CA75FA27C0 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Yes, thanks Mike.  What we're dealing with here is a bureaucracy.
>
> From: madgambler at hotmail.com
> Subject: Re: SAP_ALL SAP_NEW
> Date: Thu, 2 Jun 2011 21:02:04 +0100
> To: madgambler at hotmail.com
> CC: sap-wug at mit.edu
>
> Ah my bad, you explained your WF-BATCH user hasn't been given this for some reason? Um, why would you do that? Surely you need your Workflows to have almost superuser auths?
> Mike GT
>
> Sent from my iPhone
> On 2 Jun 2011, at 21:00, Madgambler<madgambler at hotmail.com>  wrote:
>
> Presumably you have tried regenerating SAP_ALL in the target system?
> Worth a mention just in case somebody forgot?
> Mike GT
>
> Sent from my iPhone
> On 2 Jun 2011, at 20:41, Edward Diehl<edwarddiehl at hotmail.com>  wrote:
>
>
> Thanks, Eddie, but therein lies the problem.  We've applied the note and we are still left with tasks failing because of no-authorization - and these failed to show up on the Security's authorization trace.
>
> As I asked, is anyone out there successfully using workflow where WF-BATCH does not have SAP_ALL AND SAP_NEW?
>
> Ed
>
> From: eddie.morris at sap.com
> To: sap-wug at mit.edu
> Date: Thu, 2 Jun 2011 20:54:19 +0200
> Subject: RE: SAP_ALL SAP_NEW
>
>
>
> Hi Ed, Take a look at note 1251255 which introduces SAP_BC_BMT_WFM_SERV_USER. It takes care of the authorization for the workflow runtime but you still need to add application specific authorizations. KBA 1574002 also gives details. Regards,Eddie From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Edward Diehl
> Sent: 02 June 2011 19:33
> To: sap-wug at mit.edu
> Subject: RE: SAP_ALL SAP_NEW Is anyone out there successfully using workflow with WF-BATCH carrying something other than SAP_ALL&  SAP_NEW security roles?
>
> I'm sure many of you have confronted this issue.  I would be interested to hear your experience(s).
>
> Thanks,
> Ed
> _______________________________________________
> 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 		 	   		
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110602/e982b7a6/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Fri, 3 Jun 2011 08:19:45 +1000
> From: Rick Bakker<rbakker at gmail.com>
> Subject: Re: Shopping Cart Rejections
> To: "SAP Workflow Users' Group"<sap-wug at mit.edu>
> Message-ID:<BANLkTinrN9Rx7nRpb7GcHDcrrJW3A-1-CA at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> I assume you're talking about workflows that started after the transport?
>
> On Fri, Jun 3, 2011 at 5:02 AM, BPT Consulting
> <bptconsulting at sbcglobal.net>wrote:
>
>>    Dale,
>>
>>
>>
>> Here are some other things I would check:
>>
>> Did you view the acceptance by contact person configuration in the new
>> system ? to see if transported correctly?
>>
>>
>>
>> Is it a fully rejected SC?  This configuration does not work for partial
>> rejected SC.
>>
>>
>>
>> Did you have workbench transports as well as customizing (client dependant)
>> transports ? did they both move?
>>
>>
>>
>> Are task groups TG40000003 and TG40000007 set as general tasks?
>>
>>
>>
>> Did you transport normally or using BRF_TRANSPORT_SIMPLE?
>>
>>
>>
>>
>>
>> The events APPROVAL_PROCESS_DOC* are used by Alert Management to send
>> notifications out and shouldn?t have anything to do with the process control
>> Workflow.
>>
>>
>>
>> Regards,
>>
>> Thomas Maue
>> --- On *Thu, 6/2/11, Ramki Maley<rmaley at erpworkflow.com>* wrote:
>>
>>
>> From: Ramki Maley<rmaley at erpworkflow.com>
>> Subject: Re: Shopping Cart Rejections
>> To: "SAP Workflow Users' Group"<sap-wug at mit.edu>
>> Date: Thursday, June 2, 2011, 12:57 PM
>>
>>
>> Hi Dale,
>>
>> Have you looked in the log (SLG1) and verified if your REJECTED event is
>> being evaluated at all? I will be moving our BRF config  to a QA system soon
>> and will have to see what happens.
>>
>> Regards,
>> Ramki.
>>
>> On 6/2/11 11:38 AM, Dale Brown wrote:
>>
>>   We are running SRM 7.0 process controlled workflow.  We have configured
>> the system in development to send work item back to orderer when shopping
>> cart is rejected instead of having the workflow end as the system was doing.
>>
>> We did this by setting up a brf reject event calling an expression that
>> checks current decision = REJECTED.  We then in the config for ?acceptance
>> by contact person? defined the new reject event for task 40007994.
>>
>> We also added SC to event schema for transaction type SHC .    This all
>> works fine in development.    We have since transported up to a
>> pre-production system and the rejections are back to ending the workflow.
>>
>> It looks like for WS40000015 in our development system the workflow goes to
>> step SRM Document Owner interaction (WS0000026) , where in the system we
>> transported to, the flow by-passes this step and eventually ends the
>> workflow.
>>
>> Everything looks like it was transported correctly.  We have did swu_obuf,
>> re-transported, etc.. but can not seem to get the workflow to behave like we
>> want it (as it does in development).  We also notice in the system we
>> transported to, that the
>>
>> email for the rejection is SAP?s standard email that shows it was started
>> by event APPROVAL_PROCESS_DOC_REJECTED, sub cat
>> APPROVAL_RESULT_NOTIFIC_NEW.  Does this need to be de-activated?  Is that
>> causing the problem of not
>>
>> recognizing our config?  We don?t remember de-activating anything in
>> development.
>>
>>
>>
>>
>>
>> *Dale R. Brown*
>>
>> *DUKE UNIVERSITY***
>>
>> *Sr. Analyst, IT
>> OIT - Application and Database Services
>> 919.684.5341*
>>
>>
>>
>>
>> _______________________________________________
>> SAP-WUG mailing listSAP-WUG at mit.edu<http://us.mc816.mail.yahoo.com/mc/compose?to=SAP-WUG@mit.edu>http://mailman.mit.edu/mailman/listinfo/sap-wug
>>
>>
>> -----Inline Attachment Follows-----
>>
>>
>> _______________________________________________
>> SAP-WUG mailing list
>> SAP-WUG at mit.edu<http://us.mc816.mail.yahoo.com/mc/compose?to=SAP-WUG@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
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20110603/2c8f2f28/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 79, Issue 6
> **************************************
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug

More information about the SAP-WUG mailing list