ECC 6.0 SWW_CONTOB Logical System name not being updated properly

Mike Gambier madgambler at hotmail.com
Fri Apr 11 06:51:55 EDT 2008


It's official: SAP have abandoned CHECK_OBJECT_IN_WF (and CHECK_OBJECT_KEY_IN_WF) and have also written off remote Object instances too.
 
They will be providing a 'fix' (OSS Note 1158991) to enable the FM to continue to work under ECC 6.0 to soften the blow for those people who still want to use it in the short term. Although the official word is you should switch to the WAPI as only that will be supported going forward because it looks in both container tables.
 
Which all means I suddenly have a lot of WF Event Check FMs to change, great :(
 
They still don't care that SWW_CONTOB-LOGSYS is being left blank (I feel a mod coming on for that one) but now at least I know why: there's no reason to use the field any more, because every object instance must now be local. And since the standard SWO_CREATE FM can interpret a blank value for this field and derive a Logical System at runtime they feel that a blank is just as good as a solid value.
Regards,
 
Mike GT


From: madgambler at hotmail.comTo: sap-wug at mit.eduSubject: RE: ECC 6.0 SWW_CONTOB Logical System name not being updated properlyDate: Tue, 8 Apr 2008 02:09:42 +0000


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, Mike GT> Date: Tue, 8 Apr 2008 02:03:12 +0100> Subject: RE: ECC 6.0 SWW_CONTOB Logical System name not being updated properly> From: wug at workflowconnections.com> To: sap-wug at mit.edu> > Hi Mike,> > My understanding is that the new classes aren't really supposed to> understand logical systems. If you look at the whole way that object> representations are done nowadays, it all uses Local Persistent Object> References - the emphasis here would be *Local*. So the logical system is> irrelevant. This would explain why it's been dropped and why SAP don't> care anymore.> > Remote references are a different beast and all supposed to be handled via> GUIDs (or possibly mapping tables). It is also no coincidence that the> maximum key length for Classes has been reduced from BOR's 70 down to 32> chars.> > Might not help your cause but perhaps explains some things....> > Cheers,> Mike> > > > On Mon, April 7, 2008 4:32 pm, Mike Gambier wrote:> >> > Hi all,> >> > This problem get a little bit deeper. I'm pretty sure that SAP has missed> > a trick with the 'new' 'Structure Persistence' code designed to cope with> > the 'old' BOR Object Container table SWW_CONTOB.I've been looking at the> > new ECC 6.0 code and made a bit of a discovery. Basically, the ABAP> > Classes do not understand what a Logical System is. They do not possess> > any attribute to store it, nor do they have any means to pass it through> > to functionality that will eventually invoke database updates. Simply put:> > they always assume you are dealing with local instances.> >> > Now I have absolutely no idea if this affects any of you who are using the> > 'new' OO container but it certainly affects us who want to stick with the> > 'old' BOR Container because a Logical System can be 'local' or 'remote',> > i.e. it could point to the same client/system combination you are working> > on, or it could point to a completely different client/system altogether.> >> > Take ABAP Class Method [CL_SWF_CNT_PX_CONTAINER->_container_write_values]> > as a point in case. This method is supposed to replace the old code that> > eventually calls Function Modules SWW_WI_CONTAINER_INSERT and> > SWW_WI_CONTAINER_MODIFY.> >> > It manages to work at the moment because it invokes FM SWO_CREATE which> > has a nifty subroutine in it (logical_system_handling) that copes with a> > blank value for LOGSYS being passed in. So the instantiation of an> > instance will only fail if the key is invalid for the local client. But> > since this FM does not pass out the LOGSYS value it determines at runtime> > the calling Method has no way of catching this.> >> > Worse still, when Method> > [CL_SWF_CNT_PX_CONTAINER->_container_write_values] finally gets around to> > carrying out the database updates (which it does directly I might add, bad> > SAP!) it has no way of ever passing through a decent value in LOGSYS.> >> > Hence we have blanks. And hence, I think, SAP has forgotten something.> >> > At least, that's my take on things anyway. Perhaps people here have some> > thoughts?> >> > Regards,> >> > Mike GT> >> >> > From: madgambler at hotmail.comTo: sap-wug at mit.eduSubject: RE: ECC 6.0> > SWW_CONTOB Logical System name not being updated properlyDate: Thu, 20 Mar> > 2008 17:11:38 +0000> >> >> > Official response from SAP on this one seems to be:> > Yes, there may well be a problem updating this field, but frankly we don't> > care because you shouldn't be looking in that table anyway, and you are> > very naughty for not using our WAPIs!Nice one SAP. Okay, so I made that> > last part up, but OSS Message 1153860 reads a bit like that :) I have no> > idea if this is going to cause any of you any grief, but those of you> > intending to continue using the 'old' container tables might want to keep> > an eye out for general instantiation problems with Business Objects that> > can't seem to be explained.Regards, Mike GT> >> >> > From: madgambler at hotmail.comTo: sap-wug at mit.eduSubject: RE: ECC 6.0> > SWW_CONTOB Logical System name not being updated properlyDate: Tue, 11 Mar> > 2008 14:08:33 +0000> >> > We too are on patch level 13. Our development system clearly shows LOGSYS> > values appearing regular as clockwork before the upgrade and now only> > occasionally after the upgrade, which is most odd.It kind of implies a> > deep-down MOVE statement or something not working properly to my mind.> > Probably a unicode bug or something...will see what SAP have to say. MGT> >> >> > From: araskin at 3i-consulting.comTo: sap-wug at mit.eduDate: Tue, 11 Mar 2008> > 07:49:19 -0400Subject: RE: ECC 6.0 SWW_CONTOB Logical System name not> > being updated properly> >> >> >> >> > Hi Mikey,> >> > I just took a look at our sandbox and I see a logical system in most of> > our entries. We are on ECC 6.0 patch level 13.> >> > Out of approximately 200K entries in this table, I did find approximately> > 9K entries without LogSys including _WORKITEM entries.> > I am honestly not sure why some do and some don't. Maybe others have an> > idea?> >> > Oh and you are so old school for using that table (though I do understand> > why) :-)> >> > Alon> >> >> >> >> >> >> > From: sap-wug-bounces at mit.edu [sap-wug-bounces at mit.edu] On Behalf Of Mike> > Gambier [madgambler at hotmail.com]Sent: Tuesday, March 11, 2008 6:30 AMTo:> > SAP Workflow Users' GroupSubject: ECC 6.0 SWW_CONTOB Logical System name> > not being updated properly> >> > Hi, Has anyone else noticed or seen evidence of the 'old' Workflow> > Container table (SWW_CONTOB) not being updated properly where the Logical> > System name field (LOGSYS) is concerned? I'm a little bit worried that> > this field is only sometimes being updated when entries are being added.> > Our 'new' Workflow instances do not appear to be updating this field when> > creating new entries, although any triggering event container instances do> > have their proper logical system name values.So, for example, '_WORKITEM'> > entries are being created with a blank value for LOGSYS (which just isn't> > right) whereas any importing container elements definitely do have a> > kosher value. This is causing us some grief with FMs like> > CHECK_OBJECT_IN_WF because the standard SAP code is looking for a> > like-for-like match with whatever value you pass through in OBJECT-LOGSYS.> > I'm going to trawl through OSS but I thought I'd ask around to see if this> > is a 'known' feature. I'd like to ask anybody else who is currently> > working on an upgrade project to check out their SWW_CONTOB entries too> > (that is if they still intend to use the old tables) and let me know if> > they have this problem at all, or whether it's just our system misbehaving> > :) Regards, Mike GT> >> > Think you know your TV, music and film? Try Search Charades!> >> > She said what? About who? Shameful celebrity quotes on Search Star!> >> > She said what? About who? Shameful celebrity quotes on Search Star!> > _________________________________________________________________> > Get Hotmail on your mobile. Text MSN to 63463 now!> > http://mobile.uk.msn.com/pc/mail.aspx_______________________________________________> > 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

Try Messenger on your mobile. Text MSN to 63463 Now. 
_________________________________________________________________
Amazing prizes every hour with Live Search Big Snap
http://www.bigsnapsearch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/sap-wug/attachments/20080411/f68594b5/attachment.htm


More information about the SAP-WUG mailing list