Concerning the CDATA question, you might have a look at SYNAPSE-280.
Andreas
On 15 août 08, at 11:54, Hiranya Jayathilaka wrote:
Hi,
When the FIX transport was first implemented we considered the idea
of using the Message#toXML method in the QFJ API to convert FIX
messages into XML. But since this method only returns a String,
formatted as XML and since according to the spec a user 'might' send
binary data over FIX we decided to give up on that idea and went on
to use the AXIOM API to construct the XML infoset for FIX messages.
If the users are more interested in using repeating groups than
sending binary data over FIX then I think it makes sense to make the
suggested change. Eventhough this is a critical design decision it
can be implemented with minimal code changes as Asanka has
mentioned. (Only a couple of methods in the FIXUtils class need to
be changed)
Anyway I don't understand how the CDATA sections in the XML infoset
get lost. I think the string retuned by the toXML method contains
CDATA sections. Can you explain a bit how that happens? Also how
costly is it to fix this issue in QFJ side and use a data dictionary
based approach?
Thanks
Best Regards,
Hiranya
However I don't understand how the CDATA sections get lost. I think
the XML string returned by toXML contains CDATA sections.
On Fri, Aug 15, 2008 at 12:45 PM, Asanka Abeysinghe
<[EMAIL PROTECTED]> wrote:
Hi ,
I didn't receive any response yet from QFJ guys. This is a critical
bug because without repeating group support we cannot say Synapse
supports FIX messaging, almost every FIX user use repeating group
even a small broker firm.
So we have two options
[1] Fix the bug in QFJ side and use data dictionary to identify the
repeating groups. Accessing the DD for each FIX message will effect
our message processing time because I noticed that API calls for the
data dictionary is very slow.
[2] Change the way Synapse do the FIX transformation to XML
infoset . - Current implementation access the qfj.Message and
iterate through the data structures provided by qfj and build the
AXIOM tree. My proposal is to use a simple way and it will cut down
the 100+ code to 14 lines of code.
This is the code snippet
String fixToXML = message.toXML().replaceAll("\n","");
InputStream is = new
ByteArrayInputStream(fixToXML.getBytes());
XMLStreamReader parser =
XMLInputFactory.newInstance().createXMLStreamReader(is);
StAXOMBuilder builder = new StAXOMBuilder(parser);
OMElement documentElement = builder.getDocumentElement();
SOAPFactory soapFactory = new SOAP11Factory();
documentElement
.addAttribute
(soapFactory
.createOMAttribute(FIXConstants.FIX_MESSAGE_INCOMING_SESSION, null,
sessionID));
System.out.println (documentElement.toString());
SOAPEnvelope envelope = soapFactory.getDefaultEnvelope();
envelope.getBody().addChild(documentElement);
msgCtx.setEnvelope(envelope);
This will basically create the AXIOM tree using the
qfj.Message.toXML().
Few changes will apply for the current implementation
1. Will not have CDATA section in the xml infoset
2. Attribute "id" in the element "Field" will rename as "tag"
3. Will not check binary content (FIX is not made to send binary
data, and from my past experience with the FIX users none of them
sent binary with FIX , FAST is there for binary transports for
financial messaging)
I did apply this change to my local workspace and it is working
perfectly with the FIX scenarios we have and it supports **repeating
groups** as well.
WDYT ?
If every one is happy with this change I can provide the relevant
patch.
Asanka A.
There is a blocker in the QFJ side on accessing repeating groups, I
have created the relevant issues on QFJ issue list (Jiras -
QFj-330, QFj-329), we have to wait for the QFj devs comments to
proceed.
Asanka A.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
