Re: [sap-dev] SAP no longer supporse your call of standard FM's
Posted by
Admin at
|
Share this post:
|
|
0 Comments
 | Posted by hovering_yogi (Independent SAP SD Consultant currently at Sony) on May 12 at 2:55 PM |  Mark as helpful |
See thats why I said you were the experienced developer here :-) given my
reason for their excuse was complete pants :-(
However I still don't quite see why refusing to help in this case, either
from use in custom code, or that the function module is "designed" (perhaps
better accepted) as having indeterminitely timed results means that supports
getting any worse.
Don't get me wrong I'm not trying to say that SAP support are great - I know
how difficult it can be trying to get past their first line of defence to
someone that can really help - and from experience also know that working
with SAP consultants has the benefit of them being able to log on and see
the internal updates on messages that are invisible to us customers which
can sometimes be enlightening when from an external point of view it looks
like bugger all is happening and that the response took ages to come back as
a basic "No Sorry".
Anyhow at the end of the day I kind of feel your pain, but just wanted to
chip in that maybe there's some, albeit less, pain on the other side of the
fence too?
On 12 May 2010 18:26, R. Neal Wilhite via sap-dev <
sap-dev@groups.ittoolbox.com> wrote:
>
> Posted by R. Neal Wilhite (Senior
> Project Manager)
> on May 12 at 1:28 PM
> Hi Stephen,
>
> You mentioned, "committing LUW's". However, because they force them to goto
> Update Task, there is no longer anything to go with LUW. They've effectively
> said that this has nothing to do with the LUW, so we are disassociating it
> with the surrounding process and committing it anyway.
>
> I believe that their intention was as follows:
> 1) you could be putting many Megs of text into a long text. Therefore, the
> save may take quite a long time. (for this reason, I would have prefered
> that this chioce be made in configuration)
> 2) long texts are not considered real data. As long as it eventually gets
> there it is inconsequential when.
> Therefore, even could I show an internal system problem caused by this (i'm
> sure there is one, LOL), their response would be that it is working as
> intended and you need to use something other than long texts if you want
> different results.
>
> Admittedly, the same results (and what I expected to get), but their
> initial reasoning is completely incorrect. Legally (not the correct work,
> but you know what I mean), it opens us up to even poorer support. And that
> is why Oracle tried to invade their space...
>
> Neal
>
> ---------------Original Message---------------
> From: R. Neal Wilhite
> Sent: Tuesday, May 11, 2010 8:42 AM
> Subject: SAP no longer supporse your call of standard FM's
>
> > Just for fun I thought I'd pass along a response from SAP OSS.
> >
> > I said, "...In ZVI_DELIVERY_PROCESS we call "CALL FUNCTION 'READ_TEXT'".
> It returns
> > exception 4. However, the sought long text was just saved. It was saved
> > in from the delivery and the delivery used and update task. Therefore
> > the commit of the long text is of uncertain timing..."
> >
> >
> >
> > They said, "...As we stated in our prior reply, we are unable to perform
> this type of
> > service.
> >
> > We know that you are aware of this fact, but, as per SAP Active Global
> > Support procedures, I am obliged to remind you of the services offered
> > by the SAP Support team.
> >
> > Our mission is to help you, our customers, with any error and/or bug of
> > standard delivered software licensed from SAP. When malfunctions are
> > reported (providing clear evidence that the cause can be attributed to
> > SAP licensed software), then SAP will provide support to you, our
> > customer 24x7, by providing information on how to remedy, avoid and
> > bypass errors."
> >
> > What I get out of this is that if you use one of their FM's in your code,
> just as they use it in their code, they will not support any error that
> occurs in their FM. LOL! I guess it's back to the old OSS that we know and
> love...
> >
> > Neal
__.____._ reason for their excuse was complete pants :-(
However I still don't quite see why refusing to help in this case, either
from use in custom code, or that the function module is "designed" (perhaps
better accepted) as having indeterminitely timed results means that supports
getting any worse.
Don't get me wrong I'm not trying to say that SAP support are great - I know
how difficult it can be trying to get past their first line of defence to
someone that can really help - and from experience also know that working
with SAP consultants has the benefit of them being able to log on and see
the internal updates on messages that are invisible to us customers which
can sometimes be enlightening when from an external point of view it looks
like bugger all is happening and that the response took ages to come back as
a basic "No Sorry".
Anyhow at the end of the day I kind of feel your pain, but just wanted to
chip in that maybe there's some, albeit less, pain on the other side of the
fence too?
On 12 May 2010 18:26, R. Neal Wilhite via sap-dev <
sap-dev@groups.ittoolbox.com> wrote:
>
> Posted by R. Neal Wilhite (Senior
> Project Manager)
> on May 12 at 1:28 PM
> Hi Stephen,
>
> You mentioned, "committing LUW's". However, because they force them to goto
> Update Task, there is no longer anything to go with LUW. They've effectively
> said that this has nothing to do with the LUW, so we are disassociating it
> with the surrounding process and committing it anyway.
>
> I believe that their intention was as follows:
> 1) you could be putting many Megs of text into a long text. Therefore, the
> save may take quite a long time. (for this reason, I would have prefered
> that this chioce be made in configuration)
> 2) long texts are not considered real data. As long as it eventually gets
> there it is inconsequential when.
> Therefore, even could I show an internal system problem caused by this (i'm
> sure there is one, LOL), their response would be that it is working as
> intended and you need to use something other than long texts if you want
> different results.
>
> Admittedly, the same results (and what I expected to get), but their
> initial reasoning is completely incorrect. Legally (not the correct work,
> but you know what I mean), it opens us up to even poorer support. And that
> is why Oracle tried to invade their space...
>
> Neal
>
> ---------------Original Message---------------
> From: R. Neal Wilhite
> Sent: Tuesday, May 11, 2010 8:42 AM
> Subject: SAP no longer supporse your call of standard FM's
>
> > Just for fun I thought I'd pass along a response from SAP OSS.
> >
> > I said, "...In ZVI_DELIVERY_PROCESS we call "CALL FUNCTION 'READ_TEXT'".
> It returns
> > exception 4. However, the sought long text was just saved. It was saved
> > in from the delivery and the delivery used and update task. Therefore
> > the commit of the long text is of uncertain timing..."
> >
> >
> >
> > They said, "...As we stated in our prior reply, we are unable to perform
> this type of
> > service.
> >
> > We know that you are aware of this fact, but, as per SAP Active Global
> > Support procedures, I am obliged to remind you of the services offered
> > by the SAP Support team.
> >
> > Our mission is to help you, our customers, with any error and/or bug of
> > standard delivered software licensed from SAP. When malfunctions are
> > reported (providing clear evidence that the cause can be attributed to
> > SAP licensed software), then SAP will provide support to you, our
> > customer 24x7, by providing information on how to remedy, avoid and
> > bypass errors."
> >
> > What I get out of this is that if you use one of their FM's in your code,
> just as they use it in their code, they will not support any error that
> occurs in their FM. LOL! I guess it's back to the old OSS that we know and
> love...
> >
> > Neal
Copyright © 2010 Toolbox.com and message author.
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
Related Content
In the Spotlight
White Papers
In the Spotlight
Toolbox.com for iPhone: Ask Questions & Get Answers Anywhere. Use the New iPhone App
View this thread online
Manage group e-mails
Create an FAQ on this topic
Tell us what you think
Unsubscribe from discussion
Manage group e-mails
Create an FAQ on this topic
Tell us what you think
Unsubscribe from discussion
