Early Watch Alerts one week too late

[Former Member]

Dear SAP-Crack

I installed SM and bound in all sattelite system. Then i've created Early Watch Alerts with automatic email forwarding. This works fine. The problem now is, the alerts which are sent by email are one week late. Which means, I yesterday got the Alerts from the 27th of November. Does anybody can help me?

Thx greetings

[bruno_coelho2]

Hello,

Have you solved the issue?

we are facing the same problem. We tried many things but with no success...

Best regards.

[Former Member]

Why is the date on Thursday. How can I control that?

[magexposito]

Hello Lino,

You can set on which day you want to execute the EWA reports in the Solucion Manager. Just go to transaction SOLMAN_WORKCENTER -> System Monitoring -> Setup - > EarlyWatch Alert and Service Configuration -> Configuration for a single/all solutions.

Best regards.

[Former Member]

Hi,

Did you try to de-activate the current solution and re-create a new one.??

Reg,

Nag

[Former Member]

I did. Watch the result:

EWA was created 30. November 2013...

What did i Wrong...

[Former Member]

Hello Lino,

Have you checked in SM37 if the jobs has been delayed due to any reason.

Mudasir

[Former Member]

On date EWAs are gonna be created, the duration is higher, but else there is nothing special about this jobs...

[Former Member]

Hi Lino,

Check the below note and cross check the settings

1907383  - How to setup and troubleshoot EarlyWatch Alert reports in SAP Solution Manager 7.1
       ...

1765141 - When should I replace the Service Definitions completely (Delete and Download) using the steps outlined in SAP Note 727998?

Rg,

Karthik

[Former Member]

Hi Lino,

I might be wrong but i am also facing an issue with earlywatch alerts getting generated 2 days after the scheduled date.

How many Satellite systems are there in your landscape for which EWA has to be generated?

In my landscape, there are a number of AS-JAVA for which EWA gets generated, There is a task SAP EarlyWatch Alert for all the NonABAP systems. The job/BDL/task_scheduler or processor is the one which requests session data for all the nonABAP systems.

I checked the logs and it takes about 1 hour to get the session data for one system(Could be different for you)

So if the data for a NonABAP system has to be requested, it will depend on the no. of nonABAP systems in your landscape to complete the whole procesc of requesting session data. Till then the display will be a red flag. The collection doesnt happen in parallel and this causes delay in getting the data for all of them.

Job SM:EXEC SERVICE in our system runs for a longer time due to large number of systems.

I hope this might help you as well in finding the RCA of your problem.

Regards

Aditya

[Former Member]

Hi Lino Imobersteg,

Can you paste the output of program TZCUSTHELP

Thanks,

Nag

[Former Member]

Unterstützung beim Suchen von Fehlern in der Zeitzoneneinstellung

Time setting in operating system

  system date.....................:                          11.11.2013

  system time.....................:                          10:53:43

  system time zone offset to UTC..:                          3.600

  system is currently in DST......:                          NO

  current UTC date................:                          11.11.2013

  current UTC time................:                          09:53:43

  current user date...............:                          11.11.2013

  current user time...............:                          10:53:43

  current user time zone..........:                          CET

  System time zone................:                          CET

  current system date.............:                          11.11.2013

  current system time.............:                          10:53:43

System time zone seems to be correct.

  current user date (entered).....:                          11.11.2013

  current user time (entered).....:                          10:53:00

  current user time zone(entered).:                          CET

  current user time (conversion)..:                          11.11.2013

  current user date (conversion)..:                          10:53:43

The UTC-Timer seems to be ok.

[Former Member]

Hello,

System time is ok. but this is strange.

please make sure that you have the default settings in setup for all solutions

more over try to deactivate the current solution and try to configure a new ones.

and still if the issue persists, you can demand the SAP's intervention in your case.

Hope this helps,

Rg,

Nag

[Former Member]

Some strange times in log of SDCCN completed:

	05.11.2013	11:32:15	Session download data requested using task 0000000087 by 801234	/BDL/SAPLBDL11	0	801234
	02.11.2013	15:46:37	Data collection started for session 8000000000105 EWALERT SolMan	/BDL/SAPLBDL11	0	801234

The time between two log entries. Started 02.11 ended 5.11...

No Error, no warning in this time.

[magexposito]

I don't understand why the "Session download data requested using task 0000000087 by 801234" happens after "Data collection started for session 8000000000105 EWALERT SolMan", in our systems all the EWA task start with "Session download data requested...". Could you please post the full log for the completed EWA task?

[Former Member]

Okay, i now copied the Ewa Job log out of SDCCN

SDCCN_Log_ewa.txt.zip

[magexposito]

Hello Lino,

> Searching for session data back to 20131030154637 ( 3 day(s) back)

It shouldn't say 3 day(s) back, it should be 0 day(s) back.

Can you go to Goto -> Settings -> Task-specific -> Data Request -> Settings, take an screenshots and post it here please? I want to check something abour the data collection.

Best regards.

[Former Member]

[magexposito]

Hello Lino,

Everything seems fine in the settings. Right now there I would do two things:

- Do a system trace of report /BDL/SAPLBDL11 in the satellite system, so we can see why is taking so long to get the session data back. Use transaction ST12 with the option "Trace for Current Mode" and set the trace the day before the EWA report are supposed to be generated.

- I saw in the EWA job log that the user which generate the data in the satellite system is 801234. Are you sure this user has all the authorizations needed to execute this task?

Best regards.

[Former Member]

Well yesterday i got the ewas. I looked at tha date Analysis and until date and saw that it's too late again. Analysis from 28.10 until 03.11. One week too late. Maybe it is better or a solution if i clear all jobs and ewa list. And start again. Can anybody tell me now the time services should run so i got the ewas right-dated at monday morning?

[magexposito]

Hello Lino,

Could you upload again a screenshot of your SDCCN transaction showing the completed task tab? Also in the same transaction go to Go To -> Task-Processor and post a screenshot of that window.

Is the job /BDL/TASK_PROCESSOR released in your satellite system? What is the job's period?

Best regards.

[Former Member]

The job /BDL/TASK_PROCESSOR runs once an hour. On satellite system.

[magexposito]

Hello Lino,

This can happen for several reasons. The first thing you should check is transaction SDCCN in the satellite system. Over there take a look to the EWA task and when it has finished so there could be a time gap between the starting date of the task and the ending time. In case the ending time is not strange then check when was the EWA report generated in the Solution Manager using transaction solman_workcenter.

Are the sending emails working correctly in Solution Manager? Do you know if there was any problem with it during that week?

Best regards.

[Former Member]

Hi Miguel

Well i checked the job, seems to be okay.

I know checked several EWAs. I got the mail at 4. November the Ewa was generated on 3rd of November and these dates in it...

Analysis from	21.10.2013
Until	27.10.2013

But in this EWA I saw this:

if I look on the dates i think just the "analysis from until"-date ist wrong... is this possible?

[magexposito]

Hi Lino,

This is quite strange. As far as I know when the task is processed in the satellite system then the system send the newest data to the Solution Manager, so even if you EWA is supposed to be generated on the 27th October and the data is sent on 3th October then the data that appears in the EWA report will be from the last 7 days (from 26th to 2th November).

Can you post a picture of your SDCCN transaction showing the concluded task?

Best regards.

[Former Member]

[magexposito]

Could you please send the screen of the second tab (Erledigt)? So we can check when the EWA task was done.

Best regards.

[Former Member]

Hi Lino,

Go to solman execute tcode SE38-->RDSMOP_MAIN and check the EWA service schdule date and paste the screen shot.

Also got SDCCN and check the "deleted" tab, search the session. any session was deleted in the alst days?

Normally if u configure EWA from Solman, it will schedule the maintenance package, it contain

Subtask :1-  Session Refresh

Subtask :2 - Service definition refresh

Subtask :3 - delete old session

So maintenance package will take care of EWA data collection , because Session refresh is triggered in this package.

So not required the separate session refresh schedule.

Rg,

Karthik

[Former Member]

There is nothing in the deleted tab...

[magexposito]

Hi Lino,

Thank you for posting the screenshot. As you can see in the screen there is no EWA task finished on October 27th and the first EWA task correctly finished was on November 2nd. This is the reason why you received the EWA report by email on November 4th instead on October 27th.

It could be interesting to know when the task was supposed to be completed so you can know if it was completed in time or if there was a problem that overdue the task for a week.

Best regards.

[Former Member]

Hi,

Go to solman execute tcode SE38-->RDSMOP_MAIN and check the EWA service schedule date and paste the screen shot.

it will clearly show the schedule service details.

Rg,

Karthik

[Former Member]

[magexposito]

Hello,

Just to clarify the date that appears on RDSMOP_MAIN is the date when the EWA report is supposed to be generated, not the day when it was generated. The session over there can be overdue and it will appear with a red flag but if you process the task in transaction SDCCN on the satellite system then this session will be process.

Best regards.

[Former Member]

Hi,

No over due service. so schedule the SM:EXEC service job on daily basis.

Check on the coming week EWA generation.

Rg,

karthik

[Former Member]

SM: EXEC SERVICES is planned daily. I will check that and write the happening on monday or Tuesday

Thx for your support.

[jimguo]

Hi,

How often do you run job SM:EXEC SERVICES?

Please try to schedule it to run once per day and see if it helps.

Thanks.

Jim

[Former Member]

i will check that!

[Former Member]

Well the job SM:EXEC SERVICES runs daily...

[Former Member]

Hi,

Schedule the SM:EXEC SERVICES daily in non-peak hour, it will help to generate the EWA report in weekly basis schedule(solman_ewa_admin)

Rg,

Karthik

[Former Member]

Hi,

Check in the solman_ewa_admin, for Day of the week on which EWA run.

Rg,

Karthik

[Former Member]

well all EWAs run at Sunday

Structure of the solutions is the following:

-Solution 1:

     -Solman

     -Poduction System

-Solution 2:

     -Developement

     -QAS

[bxiv]

I assume you verified that systems have the correct date?

Can you provide the job log for the sdccn for one of the systems?

[Former Member]

You mean SDCCN Log Done? or what do you need?

Transfer of session data completed to destination SM_SM1CLNT800_BACK

> transfer completed

> transfer for server beuxe01 completed

> transferring 000288 functions, 0001327969 bytes, RFC block size = 0000320000 for server beuxe01

> transfer for server beuxe01 started

> transfer data to mapped session ID 0000000108 800 destination SM_SM1CLNT800_BACK

Transfer of session data started to destination SM_SM1CLNT800_BACK

Data collection completed for session 8000000000108 EWALERT SolMan

READ_STAMP : Approximate Download with module 000153

> Difference in function interface

> CHECK_SDCCN_JOB : # of exp params in funcmod > # of exp params in mod 001191

> CHECK_SDCCN_JOB : inconsistency in # of exp params found for mod 001191

EWA_GET_PROCESSES : Approximate Download with module 000117

> Difference in function interface

> FILL_SNAPSHOT_DATA : # of tables in funcmod > # of tables in mod 000605

> FILL_SNAPSHOT_DATA : inconsistency in # of tables found for mod 000605

> FILL_SNAPSHOT_DATA : # of exp params in funcmod > # of exp params in mod 000605

> FILL_SNAPSHOT_DATA : inconsistency in # of exp params found for mod 000605

EWA_GET_PARAMETER_DATA_I : Approximate Download with module 000119

> Difference in function interface

SAPWL_WORKLOAD_GET_STATIST_I_W : Approximate Download with module 000820

> Difference in function interface

SAPTUNE_GET_SUMMARY_STATISTIC : Approximate Download with module 000829

> Difference in function interface

GET_OPMODE_USAGE_INFO : Approximate Download with module 000438

> Difference in function interface

EWA_GET_PARAMETER_DATA_D : Approximate Download with module 000118

> Difference in function interface

EWA_GET_HARDWARE_INFO : Approximate Download with module 000155

> Difference in function interface

> SFW_SOLMAN_DATA : # of tables in funcmod > # of tables in mod 000077

> SFW_SOLMAN_DATA : inconsistency in # of tables found for mod 000077

TH_SERVER_LIST : Approximate Download with module 000823

> Difference in function interface

> SEWA_GET_ABAP_DUMPS : # of tables in funcmod > # of tables in mod 001041

> SEWA_GET_ABAP_DUMPS : inconsistency in # of tables found for mod 001041

RSDDCVER_RFC_BW_WHM_STAT : Approximate Download with module 000684

> Difference in function interface

RSDDCVER_RFC_BW_STATISTICS : Approximate Download with module 000663

> Difference in function interface

RSDDCVER_AGGREGATES : Approximate Download with module 000734

> Difference in function interface

RSAR_ROIDOCPRMS_GET_ALL : Approximate Download with module 000682

> Difference in function interface

Data collection started for session 8000000000108 EWALERT SolMan

> New data collection triggered using reference session TSKR000000324

> Searching for session data back to 20131029044434 ( 3 day(s) back)

Session download data requested using task 0000004787 by USERXY

[bxiv]

Sorry about that, didn't complete my thought before hitting reply, sdccn will tell you the sm37 job name it should look like '/BDL/TASK_PROCESSOR000000#####' and is run by solman_btc.  It would also be good to know how long the job took to run, it looks like the one for my SolMan system took 112 secs to complete.