LPOR restriction v tightly-coupled SAP systems

[Mike Pokraka]

Hi Mike, 

 

I don't see this as a major hurdle. It is possible to have the same business
key for different objects in different systems. Hence they 'localised'
object references. This makes even more sense when you consider the object
type that also forms part of a LPOR: class ZCL_HR_POSITION may differ
between systems. 

 

The only thing that would be unique is a GUID, so a strategy may be to
localise your remote objects by means of a GUID and a mapping table. Your
local objects are created using a GUID and mapped to the remote business
key. Using persistency service, this is actually far easier to implement
than it sounds, and you could continue to work with your document number or
whatever in WF and nobody would be any wiser to the fact that the object
resides elsewhere. It is theoretically possible to even do without GUIDs or
mapping tables, but I'd personally avoid that for stability reasons.

 

Cheers, 

Mike

 

 

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: 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
<http://clk.atdmt.com/UKM/go/186394593/direct/01/%20>  out how.

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