on 04-12-2013 2:22 PM
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:
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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
Try class CL_GDT_CONVERSION
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
User | Count |
---|---|
95 | |
11 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.