Is this your complete Java service? Can you paste the entire code here for us to review?
Also, if you can take screen shots of your Input/Output tabs and attach it using the “Upload Attachment…” button, we will be able to better see your problem.
The code in the original posting is all the code with exception of the non editable code that IS includes in the java service developer window. The output tab has one variable called ‘handler’ that is of object type. I am running IS 4.6
To confirm that the DataHandler object type, add a “System.out.println(handler)” in your code just after you instantiate the DataHandler object. Run the Flow and check your server logs to see what got spit out. It should be apparent in your logs whether or not the handler object is of type String or of type DataHandler.
Once we confirm that, we can get back to solving why the Java service output is of type String.
Can you please paste a small screenshot of your Input/Output tabs to help out? Also, please step through your Flow using F7 and stop after your Java service executes. What is the exact value of “handler” in the pipeline?
Couple things I noticed. Don’t use an IDataHashCursor since it’s deprecated. Also, use the IDataUtil.put java method to put values in the pipeline rather than the last(),insertAfter() methods.
Ok I think I know what the problem is! You need to add that class to your Developer classpath (in addition to the IS classpath which you’ve already done) so that the Developer can instantiate it…sounds kinda crazy. I’ve had this situation before where the service runs fine but when you’re stepping through it’s not able to put the object into the pipeline. Give it a try!
Interesting call, Will!
We usually see the “Step” bug described from the other way around – somebody finds that a service runs perfectly until they start F7-ing through it and Developer chokes.
We’ll see what Rob comes back with…
If you want to pass it so something off of IS, like you need to look at how it will be serialized on the way and that is dependent on the transport that will be used. Developer to IS communication used the IDataBinCoder.
If the object is in the pipeline when returning to Developer (either when stepping through a Flow or in the final output of a service), classes that support one of the many interfaces that IDataBinCoder supports will be serialized. The final option is to try Java Serialization, which would require the object to be on Developer in order to do a Java readObject on the client-side.
When running a service, the object will still be an object while in the pipeline, so it can be passed to another service fine.
The issue I’m describing to Rob is just for Developer to IS communication. Basically IS instantiates his DataHandler class but it has no way to get to the Developer because it’s not serializable I’m assuming. So he’s just shown the object hash code as a string. By adding the class to the Developer classpath, the Developer should be able to instantiate it.