Is it possible to convert IDATA object to broker event in a java service? Note the input of my java service is a IS doc and I need to create a broker event in the java service corrresponding to the same event.
I tried doing :
Get Idata Object from pipeline
encodeToBytes
BrokerEvent.fromBinData(null,bytes)
But it gives me error Broker Data corrupted , i think because IDATA Object is of Basic Type and somehow fromBinData doesnt get Binary data it expects.
Is there any other way to go about IDATA to Broker event conversion
The best way to convert IData to a Broker event is to use a FLOW service to map fields in the appropriate publishable IS doc type and then use pub.publish:publish. Then you don’t need to mess with the IData and Broker APIs at all. You are correct–fromBinData will not do what you want.
Why is a Java service being used?
If you must use Java for some reason, familiarize yourself with reading fields from the pipeline (IData structure) and how to create broker events and populate broker fields using the Broker API.
Thanks for your reply. The reason why I am using the java service is that there is a interface which is being upgraded from version 4.x to IS 6.1. In the 4.6 there is an ATC which gets the canonical and converts it to an XML therough a complex java code. The java code has input as a broker event.
Since there is no DTD available for the XML generated out of this java code and there is llittle knowledge abt the sturcture etc of the XML, i was thinking of using the same java code in a jar and calling that method from a java service
hence i wanted to convert IDATA to Broker event to pass that canonical on to the java code.
Is the Java code doing a general purpose conversion from a Broker event to XML? Where the XML root tag is the name of the event? And the elements in the XML are simply the names of the event fields? Or is the Java code doing something a bit more specific? What is the output of the Java code–what does it do with the XML, do an HTTP post, publish a different event, etc?
Is it really an ATC component or is just a Broker client that does a conversion?
I think the approach of hosting this in IS and trying to keep the old inputs and outputs of the old code may be more trouble than simply converting the entire translation to FLOW services. Troubleshooting and supporting this would seem to be error prone as well.
If it is not an ATC component (reading/writing the ATC tracking tables) then you might consider simply keeping the Java code as a Broker client.
If by “gets the canonical” you mean subscribes to the canonical then you might consider creating an IS trigger to subscribe to that same document (event) and have it invoke a Flow that converts the document to XML.
This is a single statement in Flow (pub.xml:documentToXMLString). Even if various transformation steps had to be performed on the document prior to converting it (or a portion of it) to an XML string, it seems to be much more easily done by refactoring it out of java and into Flow.
Don’t just migrate this without really thinking through its overall design. Ask yourself, how would I do this if it wasn’t already written this way and then modify that to attempt to take advantage of what’s already there (the canonical being published to Broker, for example).
Yes I am well aware of the approach you are talking about (I have worked on more than 150 integrations upgrade and implementation of B2B and ESB in 6.1) but main intention of thinking of sticking to the java code was because the code has zero documentation and far too convoluted for project deadline that I am facing I already have the first approach (that you have suggested) in place but testing it is becoming a headache as noone is sure on the various types of constraints and validations involved.
That’s a great argument for Rob’s oft-repeated assertion “Don’t write it in Java”.
You may be stuck with java for this situation. Pass the IData in to an IS java service, iterate through its structure to populate your Broker event and then call the existing legacy java code.
Can you create an IS publishable doc type from the existing Broker event, map your source IS doc type to it and then publish it (the canonical) to Broker for the existing Broker client to pick up?
Oh well I completely concur with Rob’s theory of no java services because it defeates the very purpose of having webMethods IS flow services.
Yes but in this scenario i think finally i would have to go by the approach suggested by you of having a broker client hooked up with the as is java code…
but main intention of thinking of sticking to the java code was because the code has zero documentation and far too convoluted for project deadline that I am facing