sap-XSTRING()

This function can be used when calling an SAP RFC to generate a field value of SAP data type XSTRING or to decode an XSTRING contained in the response of an RFC. In the internal representation, each byte of the XSTRING consists of two hexadecimal digits.

The repository type XSTRING corresponds to the ABAP type "y" and it contains binary data. In SAP, the type XSTRING is used, for example, to pass to an RFC a complete XML file as a field value. Each byte is represented internally in XSTRING by two hexadecimal digits. The XSTRING format is therefore also suitable for the transfer of pure binary data/byte sequences that are not strings.

Within Lobster Integration, there is no corresponding data type. Therefore, it is necessary to constitute XSTRING fields or structural components of the RFC interface as a String field in the profile. The field length must then be at least equal to twice the number of bytes contained in the XSTRING, or 0.

The conversion of string to XSTRING is selected by the mode encode the reverse direction through the mode decode. Entering the first letter (d or e) of the mode into parameter a is sufficient.

To read a binary file from the file system and convert its contents into an XSTRING, the mode fileencode is used. To convert an XSTRING into binary data and write it to a file, the filedecode mode is used. In both cases, parameter c expects the file path instead of the encoding.

The default mode for an empty parameter a is encode.

Mode "encode"


This mode expects the XML data as a string in parameter b, usually starting with an XML header <?xml encoding=…?>.

In Lobster Integration, the data type String is always represented as a Unicode value with encoding UTF-16. To first transform the data into the appropriate encoding and then the resulting byte sequence in the XSTRING representation, the encoding must be specified as the parameter c, corresponding to the XML header but in 'Java notation'. The appropriate Java notation for XML encoding UTF-8 is utf8. Java encoding 8859_1 corresponds to ISO-8859-1. If the encoding has to be variable, and the data starts with an XML header, the encoding can also be determined from the XML header. In order to achieve this the parameter c either left blank or the value xml should be used. For the most common encodings UTF-8 or ISO-8859-n, the change into the Java notation utf8 or 8859_n is done automatically. The automatic determination of the encoding should only be used when it is unavoidable.

Mode "decode"


This mode expects the binary data from an XSTRING in parameter b, e.g. from the response of an RFC. The Lobster Integration field type, however, is a string, as described above.

The XSTRING data is first converted into a sequence of bytes. To convert this sequence of bytes into a string, the encoding must be known. It is expected as a parameter c either explicitly in the 'Java notation'. Or if it is XML data with an XML header, the encoding can also be determined from the XML header, as described above for the encode mode. For this, parameter c is left blank or the value xml is used.

Modes "fileencode" and "filedecode"


These two modes are used to convert a binary file from the file system completely into an XSTRING (fileencode) or to write an XSTRING as a binary file into the file system (filedecode). The bytes are not interpreted as characters. That is why the encoding is irrelevant here. Instead, parameter c expects the path to the binary file that is to be read or written.

The file path can optionally be a local path with a relative or absolute address or a UNC path that starts with //. If the UNC path requires a separate login, you can enter the login data after the file path, separated by a pipe character | in the form password:user@domain.

Parameters


Parameter

Description

a

Mode {encode|decode|fileencode|filedecode}.

b

Source string {encode} or hex codes from an XSTRING {decode|filedecode}.

c

Character encoding {encode|decode} or file path {fileencode|filedecode} .


Examples


Parameter a

Parameter b

Parameter c

Result


ABC123

8859_1

414243313233

encode

<?xml encoding="UTF-8"?><Umlaut>äöü</Umlaut>


3c3f786d6c20656e636f64696e673d225554462d38223f3e3c556d6c6175743ec3a4c3b6c3bc3c2f556d6c6175743e

e

<?xml encoding="ISO-8859-1"?><Umlaut>äöü</Umlaut>

xml

3c3f786d6c20656e636f64696e673d2249534f2d383835392d31223f3e3c556d6c6175743ee4f6fc3c2f556d6c6175743e

e

<?xml encoding="ISO-8859-1"?><Umlaut>äöü</Umlaut>

ibm273

4c6fa794934085958396848995877e7fc9e2d660f8f8f5f960f17f6f6e4ce4949381a4a36ec06ad04c61e4949381a4a36e

decode

414243313233

8859_1

ABC123

d

c3a4c3b6c3bc

utf8

äöü

filedecode

414243313233

file.asc

The bytes 0x41, 0x42, 0x43, 0x31, 0x32, 0x33 are written in file file.asc. The ASCII text is: ABC123. The return value is the number of bytes.

fileencode


image.gif

(The file image.gif is read in and its content is converted to the XSTRING format byte by byte. Parameter b is ignored.