LPOR restriction v tightly-coupled SAP systems

[Mike Gambier]

Hi Mark,

 

Long time no see. Staines is more icy today than snowy, very tricky driving conditions atm.

 

My 'friendly neighbourhood CRM programmer' is...me. I've been cross-trained in BDocs, BOL and am playing with Web UI stuff now in CRM 7. Um, yay!?

 

I've seen the CRM Activity stuff, the 'One' Order concept and the new Process Framework(s) too. And you know what? They're half-finished in my opinion, every single one of them. But that's beside the point :)

 

If you take PI (and particularly the ccBPM part of it), I would have thought it was obvious that a Business Process could be modelled in a single SAP box and invoke the power of other SAP boxes natively by using the remote instance concept, provided the overall risk could be mitigated properly. 

 

After all, isn't that the point of a true Cross Application Framework in principle? (Let's leave the Java bit out of the discussion though please!). If no-one at Walldorf has pondered this sort of thing before then I'd be very surprised by the way...

 

If you take CRM as another example, SAP have inherently tied the two boxes together with their ISUCRMCNCT (ISU-CRM Connector) BOR Object which is like building half of a bridge. To fudge around the limitations of LPOR they've then had to bolt on 'CRM flavoured' cross-reference tables in the IS-U stack to make sense of GUIDs being passed from CRM, instead of proper application keys. All pretty ugly if you ask me...

 

I appreciate what you're suggesting here is to fall back on asynchronous event processing and recognise the need in certain circumstances to provide a resilient platform that can cope with system outages and disaster recovery strategies. All of which means that one might be better off modelling things on both sides of the fence and passing batons around in the usual sort of relay race. Reliable, if not very elegant.

 

But, I also think there's a good argument to be made for tapping into direct calls between systems that are supposed to be tightly-coupled and avoid delays that such event processing inevitably incurs. And the switch to LPOR has made this more difficult I feel, hence my bewilderment.

 

Regards,

 

Mike GT

 


From: mark.griffiths at sap.com
To: sap-wug at mit.edu
Date: Thu, 7 Jan 2010 11:28:08 +0100
Subject: RE: LPOR restriction v tightly-coupled SAP systems







Hi Mike,
 
Hope all is well in snowy Staines!
 
In my experience if you need a workflow which crosses systems the more normal approach is to trigger events in the other system and wait for a response, or maybe even consider WF-XML.  Having said that, that could just because no one else has considered trying to use objects from one system natively in another, which I must say is a very nice idea!
 
Generally CRM and ECC workflows don’t often interact, this is because very few CRM implementations use much workflow as the CRM gods have never supported the execution of workflow work items from the CRM Agent inbox in a very satisfactory manner.  Instead most CRM workflow-like processes use CRM ‘Activities’ which do a fairly similar job to tasks from a process point of view.  In CRM to expose functionality from say an ECC system you will probably first consider the CRM BOL (Business Object Layer, but not as we workflowers know it) to do the integration – I’d advise you speak to your friendly neighbourhood CRM specialist programmer as by all accounts it is a totally different paradigm in ABAP programming.
 
Regards,
 
 
Mark
 


From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of Mike Gambier
Sent: 07 January 2010 09:42
To: sap-wug at mit.edu
Subject: [LIKELY JUNK]LPOR restriction v tightly-coupled SAP systems
 
Hello WUGgers,
 
When we upgraded to ECC 6 early last year I bemoaned the apparent demise of the Logical System field since the Workflow Gods had deemed it to be obsolete. Instead they commanded a system-wide switch to the Local Persistence way of doing things (LPOR). 
 
Despite my concern at the time, back then we didn't really have much of need to use LOGSYS because: 
 
  a) we don't use multe-clients (we still don't) 
  
and 
 
  b) we only really had 1 SAP box to worry about.
 
So I was only puzzled on a theoretical level.
 
That picture has changed though because our landscape has evolved. We now have a PI box and an ERP box playing with each other. Very soon the latter will be tightly coupled to a new CRM box too. And all three will have Workflow running on them in various forms for various reasons.
 
And there's the rub...if I wanted to model a Workflow in CRM that could natively make use of object instances that actually pointing to the ERP system this doesn't appear to be something that conforms to the new WF rules. I can already imagine a whole host of Business Processes that might want to straddle the middle-ground and work with instances on boths sides...
 
Of course the LOGSYS field is still there (for now) and I suppose I could make use of it anyway and build msyelf nice RFC-based Object wrappers and shoe-horn remote instances into our Workflows. But, I can't help but think that SAP have really missed a trick here, particularly with clients who have been suckered/persuaded* into buying a CRM-ERP platform (*delete where applicable).
 
Is anyone else here flummoxed by this decision or am I the only one howling at this particular moon?
 
Mike GT



Add other email accounts to Hotmail in 3 easy steps. Find out how. 		 	   		  
_________________________________________________________________
Got more than one Hotmail account? Save time by linking them together
 http://clk.atdmt.com/UKM/go/186394591/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20100107/7ef9e804/attachment.htm