Product/components used and version/fix level:
webMethods Integration server and test suite V10.11 (licenced products)
Detailed explanation of the problem:
I try to run tests case with mocked service.
The test fail (which is expected) if I don’t use mocked service.
But if I configure one, the test run like forever, never succeed or fail (see screen capture) and I get the following error in Integration server log:
BinCoder decode error creating Java serialized object. Excpt:java.io.InvalidClassException: com.wm.ps.serviceMock.MockObject; local class incompatible: stream classdesc serialVersionUID = -7998531444970225361, local class serialVersionUID = -7762429779639236521
I don’t understand this error message because the mocked service which is serialized/unserialized is only defined on the remote Integration server and nowhere else, why is there two different serialVersionUID and how can I fix it ?
can you provide the applied Fixes, please?
What about the data sent from Test service to Mock service and vice versa?
Might be that there are some issues with these values and not with the Mock service itself.
Thanks for your reply.
Here are the fixes installed on the integration server:
Actually the mocked service is a monitoring service which doesn’t have any output, it only send monitoring data to an external database.
It expects an identifier and the data to monitor as input.
I don’t provide any identifier because I don’t have it in test case scenario.
I tried to use an arbitrary one but I got exactly the same result with or without.
I just expect the mocked service to do nothing and skip to the next step.
I am just wondering, why there is a FlatFile Fix 10.7 applied when this is a 10.11 instance?
Latest Fix for Deployer I know of is DEP_10.11_Fix3, additionally I am missing IS_10.11_Core_Fix9 (or newer).
Tanuki has at least Fix2 available (there might be a newer one).
Please make sure all three Unit Test Framework latest fixes are installed i.e. Integration Server, Designer & Libraries.
InvalidClassException could be due to serviceInterceptor library mismatches between client and server. This should not be the case if both are at same fix level.