cancel
Showing results for 
Search instead for 
Did you mean: 

SAP workmanager Timezone settings

0 Kudos

Hi ,

We have a scenario where field user will work in two different time zones. I am trying to understand how Agentry will handle the transaction data in different time zones.

Scenario 1: User is in Time zone -1 and he is in offline. He is submitting the data in Time zone -2 . How the pending transaction values will be added to Maximo.

Scenario 2: If user moved from one time zone to other, a popup is coming saying" Timezone are changed. please logout and login again" . Even I clicked logout, user is not logging out from the app. What is the impact

Scenario 3: in some of OTB transactions, time stamp value is passed . Even this transaction is not available in transaction properties, how this is generated and how it will be maintained in different time zones.

Scenario 4: In OTB Addfieldworkorder steplet, timestamp value is used for report date instead of report date which is passed from transaction. What is the reason of taking the timestamp value and in how many transactions this was implemented.

Thanks and regards,

Shankar.

Accepted Solutions (0)

Answers (2)

Answers (2)

mark_pe
Active Contributor
0 Kudos

Shankar,

Rewriting my suggestion above to be closer to how I answer this same questions in your incident: Copying and Pasting the comments to here. To make it available online.

~~~~~~~~~~From our discussion~~~~~~~~~~~~~~

Here is how the system works:

1) The mobile device has an operating system (OS) that you can change the time zone of your device.

  • With this, the user has the option to change this on the fly and this will save the time zone on the device for all the application for the mobile device, including Agentry
  • Agentry client relies on the OS of the device to dictate what is the current time zone and time
  • Each transaction when you "Start", "Hold", "Complete" will utilized the saved time zone as listed in the OS during that point in time
  • When the time zone is not available or blank (can be caused by an initial sync during download) and when the time zone is not save during the transaction then this may mean that the time zone is null or blank. The system cannot saved to Maximo or the backend a blank time zone so during this point in time, the transmit time will be used instead of a null entry (as you cannot save a null DATE data type in the backend)

2) In the Agentry or Work Manager system, the time conversion is controlled in the Agentry.ini.

  • In the Agentry.ini there are two areas where you will need to setup your time (The agentry.ini data gets copied in the SMP 3.0 cockpit so once it is copied the agentry.ini disappears and you can now see the setup in the settings of the SMP 3.0 cockpit) - you may get the Agentry.ini again by Exporting the Application to see what yours is setup to.
  • It is in the TimeZoneAlias and the TimeZoneName.

TimeZoneAlias - is an Alias or names so that the server will understand the language of the OS of the mobile devices. Example not all OS of iPhone, Motorola, Android may follow the same syntax when they set up the time, right? So this TimeZoneAlias is to tell the server that for this time zone Alias please equate it to what the server understands.

This is best explained under these several articles:

But the simplest explanation is:

MobileDevice_TimeZone = Server_TimeZone

The MobleDevice_TimeZone is what is shown and spelled out in the mobile device when you select the time zone in the OS level. You will equate this to how the Server or PC understand this. If you are using a Windows PC, normally you click on the bottom right to set the time and date of your PC. Then you can select the time zone. It will be spelled out as understood by your PC.

Here are the articles.

TimeZoneName - This setup in the Agentry.ini is telling the SMP 3.0 (Agentry Server) to convert what was in the timeZoneAlias to the designated official TimeZoneName of your Maximo Server.

Example: Let us say Maximo is in New York (Eastern Time) while the users are in Chicago (Midwest or Central time). If they transmit, at 1:00PM going to SMP 3.0, the SMP 3.0 knows that Maximo is in New York so it will convert 1:00PM to 2:00PM before sending this to Maximo.

It is very important what you specify your TimeZoneName to be. It should be what the Server (SMP 3.0) understands (hint: check the bottom right of your PC screen and setup the official TimeZoneName).

Summary:

1. Mobile Device has an OS that requires the user to change which time zone they are at. This sometimes is done automatically by the phone to change to the correct time zone. This is the basis of what Agentry relies on. If you have a pop-up stating that you need to log off and logon this may be an internal statement stating that there will be a miscalculation if you do not turn of the Agentry client to reset. It is best to just use your application kill command (or tap to kill app) and restart the Agentry client when you are in the correct time zone.

2. It is also assumed that you have setup the timeZoneAlias of the Agentry.ini or the SMP 3.0 cockpit correctly that has all the data of your mobile OS setup before deploying to the server.

3. It is also assumed that you have properly setup the timeZoneName to properly state where your Maximo server is held or sitting at.

With those 3 items listed above, we believed that we have given you all the necessary items for you to understand on how the system works.

Now let us look at your questions:

Question 1: Scenario 1: User is in Time zone -1 and he is in offline. He is submitting the data in Time zone -2 . How the pending transaction values will be added to Maximo.

Answer: If you are travelling between time zones and you are offline, once you have saved the transaction on a particular time zone (timezone1) then when you go online in timezone 2, your data that you will transmit is still in timezone1 as the saved started time, hold time or completed time. If you setup your timeZoneName correctly then on transmit, the server will try to convert your saved data from timezone 1 to the official timeZoneName value.

Question 2: Scenario 2: If user moved from one time zone to other, a popup is coming saying" Timezone are changed. please logout and login again" . Even I clicked logout, user is not logging out from the app. What is the impact?

Answer: This may be a backup software reset requirement so that the Agentry application can be reset to not used TimeZone 1 or the prior time zone if the newer transactions needs to be saved with the new time zone. Please kill application if you are not allowed to exit or log out. This will help re-initialized your current settings. Make sure it is the correct one as understood by the OS. The Agentry application simply gets the value from the OS. This pop-up is a safety mechanism to re-initialize the data.

Question 3: Scenario 3: in some of OTB transactions, time stamp value is passed . Even this transaction is not available in transaction properties, how this is generated and how it will be maintained in different time zones.

Answer: As stated above, there may be situations that a timestamp was not saved by the user (ex: Initial sync or you got disrupted or corrupted), if there are no known dates saved, this will automatically save a JAN 01, 1901 date to the system to be processed in the backend versus a null value OR it can just use the transmit time as no dates were saved correctly. This sometimes happens on multiple transmits "start, hold, start, hold, start, hold and others) and this may occur that the last known date saved is not correct and it may use the transmit time instead. To fix something like this may require customization to start analyzing the business case on why the business model requires multi-sync setup. To do this you need to contact your SAP account executive to setup a business review case for customization (i.e. billable) or to setup error handling services.

Question 4: Scenario 4: In OTB Addfieldworkorder steplet, timestamp value is used for report date instead of report date which is passed from transaction. What is the reason of taking the timestamp value and in how many transactions this was implemented.

Answer: The answer to this is similar to the answer in 3. If the original date downloaded was null for the transaction, the client or Agentry client will not know what to put in it so it will use the transmit timestamp instead versus giving the backend null. If you have a business flow that has this issue, you may need to tweak the download data query to populate the missing dates with valid dates. This may require services engagement.

~~~~~~~~~~~~~~~end~~~~~~~~~~~~~~~~~~~

Regards,

Mark Pe
SAP Platinum Support Engineer

mark_pe
Active Contributor
0 Kudos

Hi.

Answer: In SAP Work Manager system there are 3 main components that are in play.

They are 1) The mobile device (it has its own time zone), 2) The Agentry Server (It has its own time zone) and the ERP Backend SAP/IBM (it has its own time zone).

Scenarios:

1) SAP ERP Backend (or any ERP backend) Assigns WO (approval) --> Agentry Server (receives to push or received during fetch) or <-- Mobile Client Transmit to received new WOs

2) Mobile Client transmits --> Agentry Server transmits --> SAP ERP Backend/or other ERP backend (Receives).

In the 2 scenarios above, there are certain time that gets saved to indicate which time was used.

In Agentry Server and Work Manager application, the user or administrator or installer needs to verify or approve which has the ultimate time to be used for tracking the Workorders. From here, the administrator, will use this time (X) to be the official time that needs to be used.

In Work Manager and Agentry, there are 3 areas where you need to setup the time.

1) Agentry Editor (Specifies what time the client to server will use up when it connects to the backend). - This is normally seen in the Agentry editor properties of the object that you are tracking. For example: If you have a transaction called Complete Workorder - you may have a property called Complete. In the editor, the transaction type of date and time can be modified to select to synch against the backend or not to sync or others. But in general, most of the out of the box system of Work Manager always have it set to sync to the backend time. So let us assume that you are using the out of the box setup (you can verify this in the Agentry editor).

2) The 2nd area that you need to know is each time on the mobile device you click "Start" or "Hold" or "Complete", it will use the time zone (timestamp) as dictated or used in the operating system of your mobile device. So if it is 10:00PM EET then it will use 10:00PM EET as described by the OS of your device. This is how the mobile device understands the time. It is captured within the Agentry application that uses the time as stated by the Operating System (OS - Android or iOS).

3) The 3rd area you need to know is the Agentry Server. The Agentry Server (or SMP 3.0) is installed in a PC or Linux somewhere in your landscape. The OS of the landscape is using some time zone setup. Normally in Windows this is found at the bottom right of the screen where you can see the date and time. You can click the bottom right of your date/time and setup the time zone.

4) The 4th area that saves the time is the ERP SAP time. This is normally setup under the SAP Transaction STZAC. This is normally how SAP ERP keeps track of time zone or in Maximo there is a settings that you can check to see what time zone Maximo has (can't recall the area where it is found at the moment).

The goal of an Agentry administrator is to sync all 4 of these. But normally item 1 is already pre-configured to sync out of the box. So only 2~4 are needed.

If we have to draw 2 to 4 it will look like this:

A) Mobile Client (Time) --> B) Agentry Server (Time as understood by the transaction + Convert this time to what is required in SAP ERP) --> C) SAP ERP (transaction STZAC) or in IBM Maximo (Find the official time zone).

All A to C has to be in sync.

Most of the work is done in the Agentry.ini. The Agentry.ini is your initialization or administration setup file that is configured to your Agentry Server. I need to know if you are using Agentry 6.0.X or 5.2.X version or SMP 3.0 as the instruction here even though the same, the restart technique may be different.

Let me assume you are simply using SAP Work Manager 5.2/SAP Maximo Work Manager 7.5.2 using the old stand-alone Agentry Server (Agentry 6.0.X or earlier). With this version, all the setup is done in the Agentry.ini.

Special note: Each time you modify the Agentry.ini in the older Agentry 6.0.X server or earlier, you need to restart the Agentry Server. You may also try to use the old AgentryGui and use the GUIs option to save the data to avoid restarting the server.

There are 2 things in the Agentry.ini you need to know and that is the following:

1) [TimeZoneAlias].

AND

2) [TimeZoneName]

I) TimeZoneAlias is the syntax that the mobile devices uses to name the timeZone for your mobile operating system. Each operating system is different when they spell the time Zone. Some of them may state New York instead of US Eastern Time or something else. You need to equate this to what the Server's operating system understands.

So for example: If your mobile devices users New York to state US East Coast but your Server uses (UTC-05:00) Eastern Time (US & Canada")then you have to define your TimeZoneAlias to be:

~~~~Agentry.ini~~~~~~~~

[TimeZoneAlias]

New York = (UTC-05:00) Eastern Time (US & Canada)

~~end Agentry.ini~~~~~~~

So the one on the left is how your mobile spelled it and the one on the right side of the equal sign "=" is how your PC/Server understands it (Where you installed the Agentry Server).

More information on detail instruction on how to set it up in this link:

https://wiki.scn.sap.com/wiki/display/SAPMOB/Set+Up+Time+Zone+Alias+in+Agentry.ini+Configuration+Fil...

That is just the first part.

II) Now next is to set how you want the Agentry Server to convert the received time stamp from the mobile device to the SAP ERP.

You need to setup the timeZoneName. This normally tells the Agentry server to convert all the received time to match what you have in SAP ERP. There will be calculation to convert to the correct time zone based on how you define this.

The best document here is a case study document that talks about how an attach document does not get downloaded to the Work Manager (because the time is unsync - the request was too late). In this document, concentrate on Cause 2 or Solution 2 (Time zone is not sync with ERP). I want you to study the picture of Solution 2. In this example, it will explain to run SAP transaction STZAC to find out what is your official time. From here you need to determine how to figure out how your Agentry Server (PC or Server) understands it and use that for your timeZoneName. It may ask you to go to the PC regedit to find the syntax of the timeZone name. See the pictures for Solution 2. Just concentrate on solution 2, ignore the other pictures.

https://launchpad.support.sap.com/#/notes/0002116194 <-- Check Solution 2.

In Maximo the step to check the time zone is done differently as I do not have a copy of it yet - but the idea is the same. Check in IBM Maximo the time stamp.

Now that you have setup your system properly, you will have less risk to get this problem.

The information above is the minimum requirements to make sure everything is good.

BUT..

III) Lastly there are known limitation or bugs that we have already fixed for SAP Work Manager 5.2 or later. The bugs or software limitation or SAP note are all compiled here.

So far I need you to at least read all of them as it will be important to know especially when you start upgrading to a newer version. Some of the features may still not be completed or it is still being designed. Please read all the test cases and limitation or bugs listed here.

https://blogs.sap.com/2015/11/10/troubleshooting-sap-work-manager-timestamp-time-conversion-agentry-...

Your goal is to read the 11 items tied all to time sync issues as it may tell the story on what causes or what scenarios have different fixes and yours may be all tied to it.

Those are the complete list of bug fixes and limitation as far as we know to date. If there are others it may not be ready to be shared yet.

Read limitation: SAP Note # 2233697 (https://launchpad.support.sap.com/#/notes/2233697) - as that will ultimately be the limitation of the product (both for SAP Work Manager SAP and SAP Work Manager for Maximo) and further customization tied to your environment is warranted. At this point, you will need to set up a call with your SAP Account Executive to discuss some potential customization/configuration that will be customized for your environment.

Best Regards,

Mark Pe
SAP Platinum Support Engineer