SWCONT's limitations with long values...

[Mike Pokraka]

ABAP Objects can make use of strings, and xml containers don’t live in
SWCONT. 

Come join us in the 21st century :-)

 

 

From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf Of
Mike Gambier
Sent: 21 November 2008 16:01
To: sap-wug at mit.edu
Subject: RE: SWCONT's limitations with long values...

 

Apologies for the spam :P
 
So, OK it decomposes the structures element by element (but only up to 255
chars for each). Hence a container becomes quite full of 'sub' elements
belonging to the parent element.
 
I think I knew this...been a while since I've neeeded to care about it XD
 
But...I still don't think this is ideal where the parameter will be extended
a lot...
 
I know that I can pass a multi-line table based on SWCONT into an
SWCONT-based container (so setting a container into a container as a table),
so I'm leaning towards suggesting an unstructured 'table of elements +
values' instead of a complex structure...

Pity BoR can't cope with ABAP_PARMBIND though...
 
MGT

  _____  


From: madgambler at hotmail.com
To: sap-wug at mit.edu
Subject: RE: SWCONT's limitations with long values...
Date: Fri, 21 Nov 2008 15:40:37 +0000

Hi again,
 
I forgot to mention that the example they provide where an importing
parameter structure is already longer than 255 is BoR Object Method
ISUCONTRCT.ChangeFromData where parameter ContractData is based on
BAPIISUCONTRACT which is 386 chars long in our system.
 
So, it must be able to cope somehow...presumably if I could be bothered to
debug it I'd find out how ;)
 
MGT



  _____  



From: madgambler at hotmail.com
To: sap-wug at mit.edu
Subject: SWCONT's limitations with long values...
Date: Fri, 21 Nov 2008 15:30:31 +0000




Hi,

 

I'm trying to convince SAP that using a really long structure-based single
line importing parameter for a BApI, that might grow and grow, isn't a smart
idea because SWCONT is limited to 255 chars. My fear is that we'll hit some
sort of limit somewhere which will cause problems, whether that will be in
BoR elsewhere like a BAdI.

 

They've come back and said that swc* macros can cope with longer strings at
runtime and no truncation will result. Personally I'm not convinced and can
only assume that the SAP code flicks into set/get table mode to cope
somehwere, but I can't seem to find where..does anyone here know whether it
can do this and how?

 

Regardless of their suggested approach, I want to try and impress upon them
that a nested unstructured approach is more suitable to our needs and
something more akin to SAP's Master Data Generator table EPRODA (which
assigns a type definition to an element) has more of a future in our system.


 

But they're being a bit stubborn about this and any ammuntion from the WUG
about pitfalls when using long parameter definitions like this would be
useful.

 

Thanks in advance,

 

Mike GT

 

  _____  

BigSnapSearch.com - 24 prizes a day, every day. Search now
<http://clk.atdmt.com/UKM/go/117442309/direct/01/> 

  _____  

Win £1000 John Lewis shopping sprees with BigSnapSearch.com Search now
<http://clk.atdmt.com/UKM/go/117442309/direct/01/> 

  _____  

Get the best wallpapers on the Web - FREE. Click
<http://wallpapers.msn.com/?ocid=%5bB001MSN42A0716B%5d>  here!

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