ECC 6.0 SWW_CONTOB Logical System name not being updated properly

[Mike Pokraka]

Hi (back again) Mike,

OK, as much as I enjoy a good rant against SAP when they come up with some
rather questionable designs (don't get me started on LSO!), I'm actually
still on their side on this one:

Whilst a LPOR is Local, GUID is a Globally Unique IDentifier - the
emphasis here being on Global. Hence there should not be a need for remote
instances. The philosophy has changed, the responsibility for 'remoteness'
has shifted from workflow to the application. This is particularly the
case when you start using persistent classes which do their own instance
management. So WF instantiates a Class ZCL_MYDOCUMENT with a 32 character
GUID/key. The *class* then decides whether the object is remote and goes
off and instantiates it via RFC if necessary. Workflow no longer cares.
This is essentially also part of what SOA is all about.

My experience on remote objects is very limited, I dabbled in some CRM-R/3
stuff a while back. What I remember is to the effect that the GUID for a
document can be a key to a table that tells you where the real document
resides. Details are a bit hazy but it worked.

I say this is good, because abstracting the business data from the
underlying storage was one of the original goals of BOR. Workflow doesn't
know or care what tables the data is in. GUIDs take this concept one step
further: Workflow no longer knows or cares what system the data lives in.
And so it should be.

I think why you are finding this particularly annoying is becuase you're
skipping a major version on your upgrade. The SWW_CONT* tables have been
obsolete for several years, I think since 4.6. OK, the XML stuff has some
small drawbacks, but overall I found it is indeed faster for individual
container accesses.

Cheers,
Mike

On Tue, April 8, 2008 3:09 am, Mike Gambier wrote:
>
> Hi (back) Mike,
>
> Whilst I see the point in switching to local persistence for something
> like BPM and XI, where the data will typically be stored in close
> proximity to the Workflow engine, I do not see why SAP have ditched remote
> instances for BOR Objects when they could have so easily kept them. To
> abandon the whole concept of remote instances is slightly baffling,
> especially as the BOR Container table will still exist going forward (at
> least for the time-being).
>
> To my mind (and I know this will open a can of worms in front of this
> audience), very little has changed at the deep grass roots of Workflow
> when it comes down to it in ECC 6.0. We're still dealing with RFC Function
> Module calls when all is said in done, no matter how pretty the
> polymorphic OO wrapping. I know that's a bit of a sweeping statement and
> yes I've seen there's a whole bunch of stuff with regards to inheritance,
> interfaces, error handling and tons more that now come with the ABAP
> Classes. And that's all good, so please don't confuse me for a luddite or
> a raving OO-phobe :)
>
> But what's bad, in my opinion, is that SAP seem to have decided to quietly
> decommsion an entire concept of data modelling, perhaps in the hope that
> no-one would notice. This despite the fact that they could continue to
> support remote instances because they use logical destinations as part of
> an RFC call anyway. Worse, they have left a hole, again perhaps
> intentionally, so that the old BOR Container cannot now be used to store
> remote instances after 4.6c. And it's the hole in the data that bugs me
> more than anything.
>
> I'm a little concerned that deep down somewhere in the bowels of Workflow
> a blank logical system value in SWW_CONTOB is going to cause us problems.
> More than the occasional glitch with now 'unsupported FMs'. And, as we
> know so well here, any problem multiplied by millions becomes quite a
> large pain to fix in a very short space of time.
>
> Also having something taken away without an explanantion is a bit risky
> isn't it? What if some client out there relied on instances being passed
> from one client to another and being 'available' remotely in a Workflow on
> a different client? Or, perhaps two seperate SAP systems were interfaced
> in such a way that a local instance on one system could be accessed at
> runtime directly by the other because it kept it in its container table?
> I'm not suggesting these are good examples of using remote instances but I
> think in theory they were at least possible up to 4.6c, now they
> absolutely are not.
>
> By the way, I was amused to read that the abandonment of FMs like
> CHECK_OBJECT_IN_WF was as much of a surprise to me as it was to the SAP
> guy who's supposed to look after it, or at least that's what the response
> on my OSS Message seems to imply. Apparently. I hear, there's been a bit
> of aggro internally over that which is still ongoing :)
>
> Regards,
>