EDUCAÇÃO E TECNOLOGIA

Daylight Savings in SAP Cloud Integration

In this blog post, you will learn about how daylight savings impacts your integration flows and monitoring activities in SAP Cloud Integration. You will learn about how Timezones work and how daylight savings are applied in timezones.

SAP Cloud Integration tenants across all data centers are configured to Coordinated Universal Time (UTC) Timezone. There is no daylight saving configuration for UTC. SAP Cloud Integration runtime uses the Java Timezone object to calculate the time in equivalent UTC. Multiple locations share a timezone. Therefore Java TimeZone object also includes an optional Zone ID which is defined with a geographic location. It is always recommended to selected a timezone with Zone ID especially when your region has daylight savings. This ensures the daylight savings transitions are automatically handled by the runtime. The necessary daylight saving configuration therefore comes either from the browser or the configuration with the flow steps.

Daylight savings can be a complex topic while modelling integrations. Two major features are impacted by daylight savings.

  1. Monitoring Message Processing
  2. Configuring Start Timer triggered integrations

Monitoring Message Processing

When you are checking the message monitoring entries, you will find the execution times match your local system time. This is because the SAP Cloud Integration reads the local system time from the browser and uses the value to decorate the time seen in the logs. Daylight saving settings of the local system are also read from the browser. Below is an example where the same message log is viewed from different systems in different zones.

SAP Cloud Integration Message Logs

SAP Cloud Integration message logs are generated will always report the time in UTC. The text log hence will show the time in UTC. You can access them via the Open Text View option in the Message view. The message log looks as follows.

Message Processing Log: StartTime = Wed Feb 17 09:18:30.351 UTC 2021 StopTime = Wed Feb 17 09:18:30.480 UTC 2021 OverallStatus = COMPLETED MessageGuid = AGAs32bQjinplCRoK03BDdYFqedE ChildCount = 0 ChildrenCounter = 3 ContextName = DaylightSavings CorrelationId = AGAs32YXEyNoSbbf953k6zg4Z--f IntermediateError = false Node = vsa7910585 OriginComponentName = CPI_i5091 PreviousComponentName= CPI_i5091 ProcessId = 2f11228626721021e3e8547022b7e9c4b969a4f5 TransactionId = ffe35fd0bb7c41e1ae288c8bcfa430ea

Case 1: IST(India Standard Time) UTC+5:30

The same message is seen to have executed on Feb 17, 2021, 14:48:30 when I access the Monitoring view from a laptop configured to IST timezone

Case 2: Berlin. Current Timezone: CET (Central European Time) UTC+1:00

The same message is seen to have executed on Feb 17, 2021, 10:18:30 when I access the Monitoring view from a laptop configured to Berlin timezone

Berlin implements daylight saving therefore has two different time zones associated to the place, CET and CEST. If your local system enables daylight savings, you will see that the Time shown are automatically adjusted to match the daylight savings configuration.

The daylight saving switch automatically is considered. Java TimeZone for Berlin is defined with Zone ID “Europe/Berlin”. Selecting this Zone ID would ensure automatic daylight saving transition.

Configuring Start Timer triggered integrations

Apart from the Run Once case, Time Zone is necessary for all configurations. The drop down value format is “(<UTC Offset>) <Time Zone Name> (<Zone ID>)”. Configuration view for Timer Start is shown below.

All the Zone IDs beginning with “Etc” do not have daylight savings. The necessary Zone ID information is typically known to the IT team in your company. Ensure that you select the appropriate entry from the drop down based on your daylight saving requirement.

To further assist you with determining the daylight saving information, you can execute the below script in an integration flow. Script will generate a report grouping all Time Zone values based on their daylight saving, Next Transition and Last Transition for Time Zones with daylight savings and add it to the message.

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
import java.lang.Exception;
import java.util.Map.Entry; import java.time.Instant;
import java.time.ZoneId;
import java.util.TimeZone; def Message processData(Message message) { Instant instant = Instant.now(); def withDST = ""; def withoutDST = "" for (String timeZoneEntry : TimeZone.getAvailableIDs()) { TimeZone timeZone = TimeZone.getTimeZone(timeZoneEntry); if(timeZone.observesDaylightTime()) { ZoneId zoneId = timeZone.toZoneId(); withDST =withDST + ( timeZone.getDisplayName() + "(" + timeZoneEntry + ")\n Next Transition: " + zoneId.getRules().nextTransition(instant) + "\n Last Transition: " + zoneId.getRules().previousTransition(instant) + "\n"); } else { withoutDST = withoutDST + timeZone.getDisplayName() + "(" + timeZoneEntry + ")\n"; } } def body = "Timezone Information:\n\nTimezone without Daylight Saving:\n\n" + withoutDST + "\nTimezone with Daylight Saving:\n\n" + withDST; message.setBody(body); return message;
}

The report format is shared below.

Timezone Information: Timezone without Daylight Saving: Greenwich Mean Time(Africa/Abidjan)
Ghana Mean Time(Africa/Accra)
... Timezone with Daylight Saving: Western European Time(Africa/Casablanca) Next Transition: Transition[Overlap at 2021-04-11T03:00+01:00 to Z] Last Transition: Transition[Gap at 2020-05-24T02:00Z to +01:00]
Central European Time(Africa/Ceuta) Next Transition: Transition[Gap at 2021-03-28T02:00+01:00 to +02:00] Last Transition: Transition[Overlap at 2020-10-25T03:00+02:00 to +01:00]
...

For Berlin, both the Time Zone in the drop down would work since they both implement same daylight saving.

  • Central European Time(Europe/Berlin)
    • Next Transition: Transition[Gap at 2021-03-28T02:00+01:00 to +02:00]
    • Last Transition: Transition[Overlap at 2020-10-25T03:00+02:00 to +01:00]
  • Central European Time(CET)
    • Next Transition: Transition[Gap at 2021-03-28T02:00+01:00 to +02:00]
    • Last Transition: Transition[Overlap at 2020-10-25T03:00+02:00 to +01:00]

However if we take the example of New York, we have three options where one does not have daylight saving option.

  • Eastern Standard Time(EST)
    • No Daylight savings
  • Eastern Standard Time(EST5EDT)
    • Next Transition: Transition[Gap at 2021-03-14T02:00-05:00 to -04:00]
    • Last Transition: Transition[Overlap at 2020-11-01T02:00-04:00 to -05:00]
  • Eastern Standard Time(America/New_York)
    • Next Transition: Transition[Gap at 2021-03-14T02:00-05:00 to -04:00]
    • Last Transition: Transition[Overlap at 2020-11-01T02:00-04:00 to -05:00]

So if the requirement is to have a scenario that runs at 8:00 AM every business day with daylight saving, then you must select Eastern Standard Time(America/New_York). In this configuration, the scenario will run at 3:00 AM UTC till 13-March-2021 and will execute at 4:00 AM UTC thereon till the next transition.  When you can schedule with Eastern Standard Time(EST), the execution will always occur at 3:00 AM UTC throughout the year.