troubleshooting EWA, tasks run but sessions not in satellite

[Former Member]

I am trying to troubleshoot EWA in SolMan. It has worked for ages and then it stopped. We have now implemented the latest-and-greatest ST-PI and ST-A/PI.

In SDCCN in the satellite system I see a "maintenance package" and a "session refresh", daily, both with the SolMan as their "task system".

This sounds a bit excessive to me, as note 763561 says that a "maintenance package" already contains a "session refresh".

Anyway, when I go to the SolMan, txn DSWP, and I order an "EearlyWatch alert" session for the satellite system, it never shows up in the satellite system. In SolMan it first gets the status "hour-glass" (meaning "waiting for data") and then the status "red flag" (meaning "data overdue").

The RFC-destinations are fine. Moreover, the logs of the SDCCN tasks do not show any problems with the RFC-destination.

I have forced a refresh of the service definitions: first the SolMan got new definitions from O01, and then the satellite systems got them from the SolMan.

Where do I look next?

BTW We are only monitoring ABAP.

[Former Member]

In the meantime I have submitted an OSS-message for this problem.

SAP support has suggested that I de-activate and re-activate SDCCN on the satellite systems. De-activating was simple, but I had to implement OSS-note 1303897 before I could re-activate.

Unfortunatenly, the de-activate / re-activate cycle did not solve the problem.

[Former Member]

Solved!

The installation numbers for the satellite systems, as known in the SolMan, did not correspond with the installation numbers in the satellite systems themselves.

This was a consequence of a corporate reorganisation.

I corrected the installation number in transaction SMSY in the SolMan.

[Former Member]

Hi Peter,

the job SM: SYNC SAP SESSIONS in our solman system is failing with the error Error during call of backend system. The SAP-OSS RFC is not working and says reenter password even though the password for the S-user in the SAP-OSS RFC is correct. I believe you had solved this error. Please let me know the steps to resolve this error.

Thanks

[Former Member]

Hi Peter,

I don't know if this could be useful, but if you have implemented the latest version of ST-PI addon, 2008_1_*, there is a program error and is recomended to implement SAP Note 1300023 - ST-PI 2008_1_XXX: Corrupt CCMS download with transaction SNOTE.

I hope it could help you.

Best Regards,

Tomas.

[Former Member]

Thank you.

Re: to implement SAP Note 1300023 - ST-PI 2008_1_XXX: Corrupt CCMS download

We have done that, but no, it did not help.

[Former Member]

Hi Peter,

if EWA works for Solution Manager, but not for a satellite system, that could suggest there is a problem with the service definitions on the satellite system. Did you check the logs for the deletion and replacement of the service definitions in SDCCN? It might also be worthwhile to compare the contents of table BDL2TRANS in the satellite system with another system where you're quite sure that the service definitions are in order.

The only other things I can think of to check are causes which are less likely in cases where EWA was previously working. But perhaps it's worth checking them just in case:

1)make sure the SID and installation number for the satellite in SMSY in Solution Manager are correct. Sometimes people mix up O and 0 and I and 1 for example.

2)make sure that the RFC to the Solution Manager really is pointing to the Solution Manager via sm59->R/3 connections-> <name of RFC connection>Extras->system info->target system

best regards,

-David.

PS 727998 does describe how to delete and replace the service definitions using SDCCN. The SDCCN method can also be used if the system has an RFC connection to SAP (SDCC_OSS), it doesn't necessaryily have to be a Solution Manager.(Though it usually will be.)

[Former Member]

Thank you.

Re: Did you check the logs for the deletion and replacement of the service definitions in SDCCN?

It's a long list of success messages.

Re: It might also be worthwhile to compare the contents of table BDL2TRANS in the satellite system with another system where you're quite sure that the service definitions are in order.

I compared the SolMan with a setallite system. They're identical, except that the entry for BDLFUPDEF is more recent in the satellite system than in SolMan. Odd, considering that SolMan got them from SAP SMP and the satellites got them from SolMan.

Re: make sure that the RFC to the Solution Manager really is pointing to the Solution Manager

Oh, yes, that's how the satellite systems got their new service definitions.

I'm wondering...

Session requests can be raised in SolMan. How do they get into the satellite system? Could I try to troubleshoot that process?

[Former Member]

Hello Peter,

for the EWA execution it is important that the periodic job SM:EXEC SERVICES does not terminate in the SolMan system. In case it does, one can get further information in the job log.

Best regards,

Andreas

[Former Member]

Thank you. That bit (SM:EXEC SERVICES) works and on the Monday run I see lines in the job-log like this one (one such line per satellite system):

02.02.2009 06:01:03 ( EW_ALERT ) Session 1000000000569 for 09.02.2009 created (name of the satellite system)

However, those session do not show up in the satellite systems.

[Former Member]

Hi,

Go to SDCCN of Satellite System.

1. Check the status of Task Processor.

Menu "Goto->Settings->Task Processor"; Check Task Processor Status, It should be active. If not activate it. Also check the job frequency.

2. Check the Task-Specific Settings also.

2.1. Menu "Goto->Settings->Task-Specific" .

2.2. Check the following under "Session Data Collection".

2.2.1. "Data request->Settings ". Confirm the checkbox is checked for "Allow Approximate Data Collection".

2.2.2. "Maintenance->Settings".

2.2.3. "RFC Destinations->Settings".

OR It may be becasue of the service definitons may be old.

Better you can replace SDCCN in both of the systems(Solution Manager and Satelitte Systems) as per SAP Note 727998 to replace SDCCN completely.

If you have any questions about SDCCN, Check SAP Note 763561.

Hope this may help you.

Regards,

Sanjai.

[Former Member]

Dear all.

Please, check job /??/TASK_PROCESSOR (I don't remember now the exactly name, look in SM37 for task or processor or something like that). This job execute in satellite systems the tasks of SDCCN on an automatic way. It must be running fine in all satellite systems and in solution manager too.

Hope this helps you.

Best regards.

[Former Member]

Re: check job /??/TASK_PROCESSOR

Thank you. I suppose you mean /BDL/TASK_PROCESSOR? It is running fine (hourly), in the SolMan and in the satellite systems. It doe snot seem to achieve much, though... .

The SolMan also has a number of SM* jobs, some running hourly, some running daily, some weekly.

Anyway, I found that some of them have problem at each run.

SM:GET CSN COMPONENTS runs weekly and always fails with this error:

Step 001 started (program DSWP_GET_CSN_COMPONENTS, variant &0000000000074, user ID ...

Internal error (SOLAR 001)

SM:SYNC SAP SESSIONS runs daily and always fails with:

Step 001 started (program RDSWPCISERVICEPLAN, variant &0000000000512, user ID

Error during call of SAP back end system (see long text) (SOLMAN_SAP_BACKEND 005)

The long text says:

---

Error during call of SAP back end system (see long text)

Message no. SOLMAN_SAP_BACKEND005

Diagnosis

Error calling SAP backend system: Name or password is incorrect. Please re-enterSAP-OSS via RFC destination

Procedure

Check the configuration of your connection to SAP in the Implementation Guide (IMG).

Use note 320991 to analyze RFC error codes.

Note 982045 contains information about repairing the RFC destination SAP-OSS

---

I think I have found a clue! As I understand it, it is SolMan having a problem calling SAP SMP over RFC.

[Former Member]

Thank you.

Re: Task Processor.

It is active and running hourly. In fact, I think that's the /BDL/TASK_PROCESSOR job that the other respondent was alluding to.

Re: approximate data allowed

It is allowed.

Re: RFC Destinations->Settings".

I have two of them: one entry for SDCC_OSS, with flags "active" and "to SAP",

one entry for SM...BACK (our SolMan), with flags "master" and "active".

Re: OR It may be becasue of the service definitons may be old....SAP Note 727998

Actually, I had already replaced the service definitions - not using the techniques of OSS-note 727998, but simply through SDCCN (that's possible in recent versions, if your SolMan can connect to SAP SMP).

Re: If you have any questions about SDCCN, Check SAP Note 763561.

That's what I had been doing already.

Now, one odd element: the SolMan is set up to produce EWA reports for itself, too, and that works. I am still trying to find differences in set-up between SolMan (seen as a satellite system) and the "real" satellite systems.

[Former Member]

I have fixed the matter of "SM:SYNC SAP SESSIONS", "SOLMAN_SAP_BACKEND 005" and SAP-OSS some days ago, but that did not help. Anyway, that could not explain how the SolMan was capable of producing EWA reports for itself, but not for the "real" satellite systems.