Convert xsd:dateTime to DDIC timestamp?

[JaySchwendemann]

Hi all,

I have an SOAP --> PI --> RFC synchronous scenario. One node of the request of the SOAP sender is in xsd:dateTime format with milliseconds and time zone. So the payload xml looks like this (simplified)

<Shipment>
          <ShipID>0815</ShipID>
          <Delivery>
                    <DeliveryID>1234</DeliveryID>
                    <HandlingUnit>
                              <HandlingUnitID>001</HandlingUnitID>
                              <Timestamp>2013-04-11T09:11:03.3357248-05:00</Timestamp>
                    </HandlingUnit>
                    <HandlingUnit>
                              <HandlingUnitID>002</HandlingUnitID>
                              <Timestamp>2013-04-12T13:11:03.3357248-04:00</Timestamp>
                    </HandlingUnit>
          </Delivery>
</Shipment>

As I use XSLT mapping to flatten the nested input XML to the RFC input parameters I am not able to use UDF or standard functions like DateTrans.

Having said this: What is the most sound way to send xsd:dateTime data to an RFC and use that data as data dictionary timestamp (or timestampl in our case).

Side notes:

• First I tried to just pass the xsd:dateTime as is to the RFC where the RFC expects a data element of type TIMESTAMPL. This resulted in an error on jco stating that it could not convert the xsd:dateTime to a BCD. Error text was "JCO_ERROR_CONVERSION: Number 2013-04-11T09:11:03.3357248-05:00 cannot be encoded as a BCD of length 21 with 7 decimal places"
• Then I tried to send the xsd:dateTime to the RFC where the RFC expects a data element of type XSDDATETIME_ISO (Char33). This of course worked on PI but how would I go on the ABAP side from there? I ended up, concatenating the xsd:dateTime into a asXML string like so...
  

  DATA: l_myxml                   TYPE string,
           l_timestamp_input   TYPE XSDDATETIME_ISO.
  CONCATENATE '<asx:abap version = "1.0" xmlns:asx = '
  '"http://www.sap.com/abapxml">'
  '<asx:values>'
  '<MYTIMESTAMP>'
                   <ls_hk>-timestamp
  '</MYTIMESTAMP>'
  '</asx:values>'
  '</asx:abap>'
  INTO l_myxml.

  
  ...and then using CALL TRANSFORMATION to get the timestamp back like so...
  

  DATA:l_timestampTYPE xsddatetime_long_z.
  CALL TRANSFORMATION id
         SOURCE XML l_myxml
         RESULT mytimestamp = l_timestamp.

There must be any helper class or some sort of standard mechanism to do this, right? I mean, in the end SAP does this somehow when having an xsd:dateTime in your message type and then generating a proxy from that.

Any insights on this would really be appreciated.

Cheers

Jens

[Former Member · Accepted solution]

Hi Jens,

have you checked the standard conversion table from XSD elements to DDIC elements in ABAP? There is such a table with certain rules specified (look in ABAP help for "Mapping of elementary ABAP types" or just for "XSD"), and I am confident that you'll find some information regarding date types there. When RFC or Proxy calls are sent to an ABAP system this conversion happens in the Simple Transformations (some light XSLT generated automatically).

Regards,

Jörg

[JaySchwendemann · Accepted solution]

Hi Jörg,

thanks for the input, yeah, I found a table, although Timestamp is not an elementary data type and therefore is found in this table (for reference --> http://help.sap.com/abapdocu_702/en/abenabap_xslt_asxml_schema.htm)

Acutally as stated above I'm already using XSDDATETIME_ISO and XSDDATETIME_LONG_Z to convert the timestamp using CALL TRANSFORMATION.

Could you please elaborate on how you would handle this? Am I on the right track already or am I doing this overly complicated?

Thanks and kind regards

Jes

[Former Member · Accepted solution]

Hi Jens,

the help page you quote tells me that your conversion should actually work out-of-the-box:

"A deserialization accepts XML values in UTC format (closed by Z) or with time zones (closed by {+|-}hh:mm). The time zones are converted to the appropriate UTC value. No precision may be lost during deserialization. This means that only XML values with a maximum of seven decimal places can be deserialized."

I would expect that the deserialization works automatically and gives you the desired ABAP type, no need for further conversions. In case it doesn't maybe you miss some setting or maybe you better open a call with SAP.

Regards,

Jörg

[JaySchwendemann · Accepted solution]

Hi Jörg,

hmm maybe I was doing something wrong within mapping but I already tried to just map xsd:dateTime to DDIC TIMESTAMPL withouth success.

However, I'll open a call to SAP and keep you updated on the outcome. Thanks for your valuable input so far.

Jens

[Former Member · Accepted solution]

Hi Jens,

the point is that you don't need to map explicitly. You keep it as xsd:date in PI mapping and pass it this way to ABAP. The proxy framework then automatically generates the corresponding data types and a transformation that converts the xsd:date to the corresponding data types. So if your xsd type is generated in ABAP as TIMESTAMPL the transformation will automatically do the appropriate conversion.

What I am describing is the ABAP proxy scenario, probably in RFC calls this function is not available (since you import the RFC to PI, not the PI model to ABAP). Anyway, you may want to check out the proxy/webservice option for this functionality, since it could save you this kind of trouble.

Regards,

Jörg

[LeonvNiekerk]

Try class CL_GDT_CONVERSION

[ambrish_mishra]

Hi Jens,

I suggest you play with the content of the MYTIMESTAMP field, remove hyphens, colons etc and make it similar to YYYYMMDDhhmmssmmmuuun which is the UTC Time Stamp in Long Form in ECC for Data element TIMESTAMPL. You may end up trimming the field length to 21 characters but you need to check if it meets the requirement and no data loss happens.

Hope it helps.

Ambrish

[JaySchwendemann]

Hi Ambrish, this solution would be feasible if I wouldn't have to handle time zones. However, sender is situated in the US where receiver is situated in Germany.

There are date conversions in XSLT 2.0, I know, but from the top of my head PI doesn't support those albeit it supports a few XSLT 2.0 functions even as it is only officially certified for XSLT 1.0

Does this make sense? Thanks for your input

[ambrish_mishra]

Hi Jens,

I am trying to understand your requirement. Are you trying to do time zone conversion before calling the RFC (AMT to BST or something similar) ?

Ambrish

[JaySchwendemann]

Hi Ambrish,

sorry if I haven't been detailed enough. The "MYTIMESTAMP" field within SAP is part of an already possible solution i came up with. Having the xsd:DateTime mapped to a XSDDATETIME_ISO (Char33) data element and the using CALL TRANSORMATION within RFC is working fine. I was just curious if this is the best solution.

Having said that and answering your question: No, I would not want to make any time zone conversions within mapping (so before calling the RFC).

My hopes when I initially set up this scenario where that just using xsd:DateTime on the sender side and TIMESTAMP / TIMESTAMPL on the receiver side would suffice, but that seemed not to be the case, hence the question.

So is there a more simple / more "standard way" of a solution to this than that what I came up with?

Cheers

Jens