SLD in R/3 4.6C and WebDynPro calling BAPI from EP7.0 to 4.6C

Question

Hi,
First let's describe the landscape :
- EP7.0
- R/3 4.6C
Second, the goal : I want to do WebDynpro that will communicate with the R/3 4.6C.
To achieve that, a EP7.0 (based on NW2004s SR2 that was "upgraded" to SPS10) was recently installed.
No problem with this one. The SLD server (local server) is installed on this portal.
As there is no gateway on the portal, I took the gateway of the R/3 4.6C for the SLD server.
The ABAP system was created manually in the SLD server.
I then created the two JCo and it seemed to work fine (as least the tests were OK)
When I created a WebDynPro that I published on the portal I was able to retreive the BAPI of the R/3 server, I was able to send him my requests but I received nothing from the R/3.
I also noticed when I tried to configure SLD in the R/3 that the tcode SLDCHECK, SLDAPICUST were not present. Do you need a defined SP level to be able to run them ? Are they important for my use ?
The question is : is my configuration wrong (SLD...) or is my Java code in the WebDynpro wrong ?
TIA,
Denis.

Answer 1

Raghav,
The most common reason for this error is exactly what it says, you have somehow overlooked including a material/plant in a PR IM.
Go into the failed queue, find all material/plants that exist in the failed LUW.  Enter these one by one into CFM5 in R/3.  You should have one and only one active model for each of these materials.  Inactivate all but one IM if there are multiple PR models active.
If this PR is for a STO, then you must have open active IMs for both the source and destination plant materials.
Now, you say that in SCM you cannot select the models, this means that they are not active and valid.  If you can find the model in R/3, but Delta3 can't find it, it implies that there is some type of error with connectivity, perhaps in your system destination definitions.  Wrong RFC connection name, wrong server id, wrong client, etc in SM59.   Or, wrong logical system name.  Check these on both sides.
More unlikely, but also possible, check is for inconsistencies in the IMs.  In R/3, run RAPOKZFX.  Regenerate your IM runtimes with RCIFIMAX.
Finally, it is possible that you have userexits that are impacting the CIF.  Talk to your developers to see if any have been activated.
Best Regards,
DB49