Skip to Content
avatar image
Former Member

SLT Real Time replication via ODQ from ERP does not send new records to BW DSO

Hello.

We are currently trying to implement a real time replication scenario transferring data of a table in ERP replicated via an SLT server to a BW on HANA system using ODQ. However no changes in the table are transferred to the DSO in BW.

We have been following presentations and video instruction but did not succeed in the end. The following steps we did:

1) Creation of a configuration in SLT – source RFC to the ERP system, target RFC to the SLT with ODQ as scenario.

2) Creation of source system in folder “ODP SLT Queue” in BW connecting to the configuration in the SLT server.

3) Creation of data source using the SLT source system by selecting some small table from the list of ERP tables.

4) Creation of DSO and transformation comparable to the source table structure.

5) Creation of real time DTP.

6) In the RDA monitor we generate and execute a repair process chain – it derives all records from the source table in ERP – these appear active in the DSO.

When we add a new record to the ERP table it is not replicated to the DSO. In the ODQ monitor on the SLT we see the DTP and the open request as subscriber but the number of units and rows is zero.

But when we switch to the unit view there the added records appear and the values are correct.

Therefore we assume that the issue is somewhere in our ODQ configuration. We have checked the background job on the SLT server ODQ_DAEMON_CLIENT_001 and it is running every 15 min for not more than 2 seconds.

Is it correct that the job only runs short? Our understanding was that the job will run for 15 mins checking the queues every 15 seconds and sending an RFC to the BW when required so the BW will extract the data.

In the job log there are only 2 messages (“End of daemon period: 17.06.2015 at 00:29:31. Takt time is 15 seconds” – the end of the daemon period is exactly 15 min minus 15 sec after the start / “Notification task 1 started on server cuvdhan03_V08_00”). We do not know if the system executes the RFC call. In the transactions SMQ1/2 nothing is recorded neither in BW nor SLT and we do not know any other way to check.

We have checked the SAP notes but the only one we found was related to missing authorization (the system users have SAP_ALL and SAP_NEW as well as the specific profile for BW background users (S_BI-WX_RFC in SLT, S_BI-WHM_RFC in BW).

Our version are the following: DMIS on ERP 2011_1_731 SP7, DMIS on ERP 2011_1_731 SP8, BW 740 SP10.

Could somebody please comment how the ODQ_DAEMON job should behave?

Are there any other jobs which are relevant and which we could monitor?

Can we see somehow if the SLT sends the information about updates to BW via RFC?

Does anybody have any idea what we are doing wrong?

Many thanks, Thomas

image004.jpg (40.6 kB)
image002.jpg (36.6 kB)
image006.jpg (26.2 kB)
Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Jun 29, 2015 at 02:21 PM

    The latest info is that it still does not work. However we have narrowed the issue to the ODQ_DAEMON job in SLT.

    We have set up the same in a secondary test environment and it works smoothly from the beginning. There the ODQ_DAEMON job runs as we expect - always 15 mins (or the time we specify in the scheduling) and then restarts. In the job log you see the check for new records every 15 sec.

    Still we do not know why the job in our main system is not doing anything. Debugging seems difficult as it behaves differently in dialog.

    The setup was the same in both systems - the only difference is the DMIS version of the SLT. The working environment is one SP lower than the non working (SP7 compared to SP8)

    Any hints what could be the issue?

    Thanks,

    Thomas

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Prabhith Prabhakaran

      Hi Prabhith,

      now SAP identified the issue. We had a mismatch in our time settings (difference between system and UTC). This could be seen in the report TZCUSTHELP. This one was showing the following in our SLT system:

      Time Setting in Operating System
        System Date.....................:                          09.09.2015
        System Time.....................:                          07:14:41
        System Time Zone Offset to UTC..:                              0
        System Currently in DST.........:                          NO
        Current UTC Date................:                          09.09.2015
        Current UTC Time................:                          07:14:41
        Current User Date...............:                          09.09.2015
        Current User Time...............:                          10:14:41
        Current User Time Zone..........:                          EET
        System Time Zone................:                          CET
        Current System Date.............:                          09.09.2015
        Current System Time.............:                          09:14:41
      System time zone or UTC timer is incorrect

      Now that we have adjusted offset to utc and DST we get the message that it is correct and the replication works.

      I hope this also helps in your case.

      Best regards,
      Thomas

  • avatar image
    Former Member
    Sep 08, 2015 at 07:49 AM

    Hi Prabhith,

    the issue still exists. I have opened an oss message for this and I am currently discussing with a Developer from SAP. When I have a solution I will post a reply here.

    Best regards,
    Thomas

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hi Nilesh,

      it sounds strange that you only have this issue for a specific table. In our case we never received any delta records. As this is a global error it should impact all replications.

      Just in case I would try to fix this but probability is high that the issue might not be solved by this.

      You may have to go for oss support which was the only help for us as well.

      Best regards,

      Thomas