In a recent project, we worked with the Oracle Application Adapter for SAP R/3 in order to retrieve data from and publish data to the customers SAP system. Did you ever have a look at an XML-based intermediate document (IDoc) from SAP? Well, good news is that you get structured data. Each IDoc type comes with a schema definition as XML Schema Definition (XSD) which can be retrieved from the SAP system using Oracle Application Explorer. Bad news is that absolutly everything is stored as xsd:string. No matter the content of the element, if it's some numeric values, text, date or time values ... the values are stored as string. SAP doesn't make use of the more appropriate default datatypes or the XML Schema Definition.
However, other sources do. So if you want to use for example the header data of an XML IDoc DC40 fragment to call a web service, you need to transform the string based date value
CREDAT and the string based time value
CRETIM to the more appropriate xsd:dateTime.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:sap-com:document:sap:idoc"
xmlns="urn:sap-com:document:sap:idoc"
elementFormDefault="qualified">
<xsd:element name="IDOCTYPEOFYOURCHOICE">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="IDOC" maxOccurs="unbounded" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="EDI_DC40">
<xsd:complexType>
<xsd:sequence>
...
<xsd:element name="CREDAT" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="8"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="CRETIM" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="6"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
...
</xsd:sequence>
...
</xsd:complexType>
</xsd:element>
...
</xsd:sequence>
...
</xsd:complexType>
</xsd:element>
</xsd:sequence>
...
</xsd:complexType>
</xsd:element>
</xsd:schema>
You can achieve this by assigning string data in the correct pattern to an
xsd:dateTime element. This is possible since
xsd:dateTime is accepting string inputs. However, the pattern of xsd:dateTime has to be respected. For our example, it is enough to target the pattern
"yyyy-mm-ddThh:mm:ss" without the optional milliseconds and time zone parameters. Check out detailed information in
XML Schema Definition Part 2 Datatypes.
The little POC for this is based on a synchronous BPEL process waiting for input data similar to XML IDoc data. An XSL Transformation is used to transform the string-based input data to
xsd:dateTime data. Additionally, the XSL engine will add a generated
xsd:dateTime value of the runtime environment. The following figure shows the BPEL process.
 |
| BPEL process GenerateTime |
The service component architecture diagram is as simple as that, showing the exposed service endpoint and the BPEL process.
 |
| SCA composite overview of the POC |
The input data to the request contains two elements date and time. Both of them are simple types based on xsd:string and restricted in length of 8 respectively 6 characters to represent a date of patter
"yyyymmdd" and time of pattern
"hhmmss".
 |
| XML Schema definition of the POC |
The response data on the other hand contains two
xsd:dateTime elements. One of them will be the target of the XSL transformation while the other one will hold engine generated data.
The following screenshot is taken from the XSLT editor in JDeveloper with SOA extension.
 |
| XSL Transformation is XSLT editor |
We are using substrings to extract the year, month and day fragments from the input string date. The same way, we are extracting the hour, minute and second fragments from the input time value. Afterwards, we are concatinating all fragments including the required separators to the desired pattern of the
xsd:dateTime based value
ns1:customDateTime. Please find below the source code.
<xsl:template match="/">
<ns1:response>
<ns1:customDateTime>
<xsl:value-of select="concat(
substring(/ns1:request/ns1:date,1.0,4.0),'-',
substring(/ns1:request/ns1:date,5.0,2.0),'-',
substring(/ns1:request/ns1:date,7.0,2.0),'T',
substring(/ns1:request/ns1:time,1.0,2.0),':',
substring(/ns1:request/ns1:time,3.0,2.0),':',
substring(/ns1:request/ns1:time,5.0,2.0))"/>
</ns1:customDateTime>
<ns1:generatedDateTime>
<xsl:value-of select="xp20:current-dateTime()"/>
</ns1:generatedDateTime>
</ns1:response>
</xsl:template>
Now let's test the process (and XSL transformation) from Enterprise Manager, providing some sample data ...
 |
| Input data for testing |
... and we are successfully receiving the transformed data as response:
 |
| Output data of the test |
Notice that our transformed
xsd:dateTime value only comes with the precision of the provided input data while the generated timestamp comes with the complete, detailed
xsd:dateTime pattern including the optional parameters of milliseconds and time zone.
Here you can download the complete POC.
