This one is baking my noodle for some time now. Currently we are in a mixed environment of webMethods 6.5 and webMethods 8.0. JDBC Adapter on both is 6.5. They both make JDBC connections to JDEdwards World (on i5/OS V5R4) and JDEdwards EnterpriseOne (on i5/OS V6R1).
The JDBC drivers in use on the wM8 are the latest ones from JTOpen (v7.1) and when checking the classpath of the IS the jt400.jar is loaded from the \SoftwareAG\IntegrationServer\lib\jars\ folder.
On both IS environments we have the same behaviour: for JDEdwards World (V5R4) when setting up an adapter service the . works fine and allows us to select the correct table, independently from the environment (DV, TST, PROD). When promoting new code from one environment to the other, no extra action are required.
When connecting to the EnterpriseOne partitions (V6R1), the . remains empty upon creation of an adapter service. We have a workaround though but it is quite dirty: after the adapter is created we save and close it and we then unleash another service on it that makes some changes in the node.ndf of the adapter service. This works fine until you open the adapter service (even without saving).
This is not a very pleasant way of working because another side effect is that most of the time you do not see the input and output variables of the adapter service in the pipeline. Therefore you have to open it again and point to the .actual_lib.filename.
Once in PROD and without doing any changes to the code, the adapter and connections are running as it should, without any problems.
And now the 1 million dollar question: how do we get the JDBC adapter to cooperate with V6R1? I have been through tons of documentation, forums, … but no-one seems to have this problem or it would like 5 years ago. SAG support, while extremely helpfull at times, is passing on this one as the JDBC drivers themselves are not their responsibility, which makes sense.
Feel free to shoot any question that comes into your mind. For completeness I provide you the JDBC connection involved. The cliSchema property was my latest test, without any result.