Can 'getLastError' return objects in its 'pipeline' output?

[Sonam_Chauhan]

Thanks again @John_Carter4, SAG plans to update documentation with the workaround you provided.

“we will update the webMethods IS Build in services reference document and the webMethods Service Development Helps from version 10.1 until the latest. In webMethods IS Build in services reference document, we will update the usage note for pub.flow:getLastError build-in service, while for the webMethods Service Development Helps, we will add and update the section for TRY CATCH.”

Maybe in future R&D can force serialization to elements declared in Flow Try block:

Force serialization of unserializable Java object?

…Or use the Java ‘Try-with-resources’ method that exploits the AutoCloseable interface:

Java Language Tutorial => The try-with-resources statement

[reamon]

The try-with-resources concept could be useful in FLOW. Indeed, I just had a use for something like that where it needs to make sure to close a file after opening and reading via stream (using flat file services).

That said, I always worry when FLOW starts adopting Java-like constructs. (With apologies to Dennis Miller…) Not to go off on a rant here, when I first saw the new try/catch/finally structures I was intrigued. But after digging into the details and seeing how it is trying its best to mimic try/catch/finally of Java I was less enthused. Then when we found that the handling of the pipeline differed significantly I was dismayed. As noted in my earlier post, the try/catch/finally can be useful if one understands the specifics. But it is not a direct drop-in replacement for the nested sequence approach (which definitely has its own limitations).

Since the beginning of Integration Server (even when it was B2B Server) there has been tension between coding with FLOW vs Java. There have been multiple discussions about when to use each. Those will continue, I’m sure. My position has always been, if you want to write primarily Java code, use a different tool. Integration Server is not a Java development environment. IMO, part of the reason for its success and longevity is specifically because it is not a Java development environment. It’s primary language is FLOW.

Striking the balance between adding useful FLOW features but avoiding being “too much like” Java is a challenge. IMO, the try/catch/finally went too far. (And the unit test framework based upon JUnit went off the rails but that’s another topc. )

Regarding the “force serialization” aspect, instead of trying to force serialization of objects that likely have good reasons for not being serializable, perhaps the focus could be on not copying the pipeline. I clearly don’t know anything about how the pipeline(s) are managed under the covers, but perhaps there is a way to keep vars in the try block as accessible/functional in the lastError/pipeline.