Skip to Content

This blog belongs to series blog post Master handling Date/Time in E2E Fiori Scenario.

You can view the index page by click following page.

Master handling Date/Time in E2E Fiori Scenario

 

In my previous blog, I summarized common possibilities of handling Date/Time in ABAP. In this blog, I want to show you what is happened to those fields when developing OData service.

 

1.Summary of methods of creating OData service in Netweaver AS ABAP

There are 4 common ways of developing OData service in Netweaver AS ABAP, they are:

a) Create OData service metadata in Gateway Service Builder (SEGW), then implement the backend logic using ABAP code( OData Channel)

b) Create OData service metadata in Gateway Service Builder (SEGW), then mapping the implementation to a predefined object ( like Core Data Service, DDIC Table/View, RFC … )

c) Create a Core Data Service view, then exposure it as OData service by add @OData.publish: true annotation

d) Create a Core Data Service view, then use it as a reference in Gateway Service Builder (SEGW).

I’ve tested on all options for scenarios involved in this blog. Besides some minor difference which I will mention in this blog post, the behaviors are identical among those methods.

2.Type mapping and auto conversion between ABAP data type and Edm datatype

The diagram below shows data type conversion during the lifecycle of extracting date/time from DB to OData service.

 

Just remember all types except Time will parse to Edm.datetime by default. If it is outputted as JSON( $format=json), the result should be a Javascript Date. In all other cases, a string is generated.

*Date in JSON format is not JS Date type, but if you are using SAPUI5 and OData model, the framework will convert it into JS Date. Thanks to Cris Paine for helping to find this mistake.

In the table below, there are some examples

ABAP Type ABAP Value XML Output JSON Output Remark
DATS 20180206 2018-02-06T00:00:00 Date(1517875200000)
TIMS 104433 PT10H44M33S PT10H44M33S
Timestamp(short) 20,180,206,104,433 2018-02-06T06:44:33 Date(1527921873000)
Timestamp(long) 20,180,206,104,433.1234567 2018-02-06T06:44:33.1234567 Date(1527921873123)

*JSON output is milliseconds since 1970-01-01

*Since JSON output’s precious only to 10E-3, when outputting as JSON, it cannot represent full precious of long timestamp.

*Only technical conversion, the framework don’t take timezone into consideration!

Best Practice: Avoid use time standalone when publishing OData, if possible,  use timestamp(short) if you need to output time.

3.Null and default values

There are some cases that your date/time fields don’t have a value, the ABAP server indeed allow this situation, let’s see how to handle and identify this case when publishing OData service.

3.1 For Edm.Datetime

DATS, Timestamp(s, hort and long) are converted to Edm.Datetime.

Edm.Datetime is nullable, for DATS without a value or have a value ‘00000000’, a string value ‘NULL’ will return when outputting as XML and a JS null value will return when outputting as JSON.

To enable this feature, you need to add nullable = ‘true’ in OData metadata, otherwise, you will get a 500 error when accessing this record.

If you are using method c) or d) mentioned earlier to create your OData service, the Edm.Datetime field is set to nullable by default so that you need to do nothing.

If you are building OData metadata yourself( method a) or b) ), you need to do as following:

a) In transaction SEGW, open your OData service project and switch to edit mode

b) Expand <your project> –>Data Model–>Entity Types–><Your entity type>, then double-click Properties

c) On the right side of your screen, click the checkbox in column ‘Nullable’ of the line representing your date/timestamp field

d) Generate your OData service again.

 

3.2 For Edm.Time

It is a little different for Edm.Time.

Not like a date, the value ‘000000’ has its meaning, it representing ’00:00:00′.

Edm.time won’t accept null value even if you set it nullable, but it treats ‘000000’ as a normal value.

 

4.Invalid Values

Since ABAP stores data/time values as other types like char, decimal, it does allow invalid date/time values such as 20181315 in the database.

When ABAP come up with OData service, all invalid values will lead to 500 errors.

 

5 Troubleshooting

All date/time errors lead to 500 error, like the following image.

It hard to get the reason from this. Just copying the transaction ID marked in the screenshot.

Then log on to your front-end server of SAP Gateway, enter transaction /n/iwfnd/error_log and find your error through transaction ID you’ve just copied.

You will find all errors related to date/time have the following information

T100 Error ID: /IWFND/CM_CONSUMER122

Error Text:  Invalid format (return <structure/table>): Property Name ‘<Property Name>, Property Value ‘<value> ‘

6.Summary

After reading this blog, I believe you will know what will happen when exposing your data as OData service and can anticipate possible exceptions and problems before you start work.

In next blog, we will go to the frontside to see how SAPUI5 handle date/time fields.

 

 

 

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Chris Paine

    I would also note that the  JSON reprentation of a datetime isn’t a JS date, but can be used to construct a JS. Some frameworks aware of the OData metadata can do this for you, but it isn’t automatic and does rely on the additional metadata call.

    Otherwise biggest thing to be aware of is time zones! Do not assume your user is in same timezone as your server.!

     

    Good post 🙂.

    (2) 
    1. Steve Guo
      Post author

      Thank you for the reminder!  I will add a note to the JS date thing.

      For the time zone, it is really easy to confuse that I need a single blog to summary time zone issue in the whole process.

       

      (1) 

Leave a Reply