I have a email multi-part message which I am using to send failed message routing from the messagebox to a business users mailbox.
Email{ Body - RawString; OriginalMessage - string};
The original message gets set from the received message that activates the orchestration. For example assume the original failed message is from a Flat file that failed disassembly with the contents:
Order,1,2,3,4,5,<6>,
I set the message using:
Email.OriginalMessage = MyUtil.XlangMsgToStringMethod(FailedMessage);// XmlDocument type, this can be malformed xml, valid xml, or flat file that fails in disassembler.
I can then write to the event log to test whats in Email.OriginalMessage:
System.Diagnostics.EventLog.WriteEntry("BizTalk Server 2006", Email.OriginalMessage, Information); // This displays the correct original message "Order, 1,2,3,4,5,<6>,"
When the email is delivered using a SMTP server and a dynamic send port, with the attachment set to text/plain mime type, the original message gets xml encoding escaped and wrapped in xml:
<?xml version="1.0"?>
<string>Order, 1,2,3,4,5,<6>,</string>
Any ideas why? The SMTP port has passthrutransmit as pipeline.
Thanks.
SMTP port is getting XMLTransmit forcing the message to be treated as XML.
Switch to PassThroughTransmit.
Related
Out of nowhere, jmeter started failing 100% for my normal web service requests. Upon further analysis found that, at server empty request is received. Attached viewresultstree listener with all flags ON and found below error
<?xml
version='1.0' encoding='UTF-8'?><ns2:Fault
xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns3="http://www.w3.org/2003/05/soap-envelope"><faultcode>ns2:Server</faultcode><faultstring>javax.xml.bind.UnmarshalException
- with linked exception: [com.ctc.wstx.exc.WstxParsingException: Unexpected close tag </Client>; expected
</EOF>. at [row,col {unknown-source}]:
[24,16]]</faultstring></ns2:Fault>
I can say that there is no XML parsing exception. Can someone please help me on this weird jmeter behavior?
Found the issue, it was with the input file. somehow the input file turned into empty file which was providing EOF for input parameter and hence the request was being treated as ended when this first EOF appeared at server HTTP endpoint.
Fixing this input data file resolved this issue to me. :)
What I am tried to do is to have a lambda function proccess emails forwarded by mailgun.
So far, I have setup mailgun's route so it will forward emails to a AWS api gateway, then the api gateway triggers a lambda function.
The problem comes when I try to process the mail, instead of getting a pretty Json that I am expecting inside the lambda's event.body, I m getting raw post form data like
--cff4e6b3-a3a4-4131-bb8d-90a73f1b4c36\r\nContent-Disposition: form-data; name=\"Content-Type\"\r\n\r\nmultipart/mixed; boundary=\"001a1140216cee404d05440c49e7\"\r\n--cff4e6b3-a3a4-4131-bb8d-90a73f1b4c36\r\nContent-Disposition: form-data; name=\"Date\"\r\n\r\nTue, 20 Dec 2016 13:40:53 +1300\r\n--cff4e6b3-a3a4-4131-bb8d-90a73f1b4c36\r\nContent ......
My question is, what should I do to get the JSON version of the forwarded emails in lambda?
Not sure if you ever came to a solution, but I have this working with the following settings.
Setup your API Gateway method to use "Use Lambda Proxy integration"
In your lambda (I use node.js) use busboy to work through the multi-part submission from mailgun. (use this post for help with busboy Busboy help)
Make sure that any code you are going to execute after all busboy is complete is executed in the 'finish' portion of the busboy code.
This suggests that your mailgun route is misconfigured and ends with a MIME request:
When you specify a URL of your application as a route destination through a forward() action, Mailgun will perform an HTTP POST request into it using one of two following formats:
Fully parsed: Mailgun will parse the message, transcode it into UTF-8 encoding, process attachments, and attempt to separate quoted parts from the actual message. This is the preferred option.
Raw MIME: message is posted as-is. In this case you are responsible for parsing MIME. To receive raw MIME messages, the destination URL must end with mime
From Receiving Messages via HTTP through a forward() action
I am trying to publish a json message using the Amazonsns connector in WSO2 ESB 4.9. I am able to successfully publish a simple string message however when I set the messagestructure to json in order to send different messages to different platforms and attempting to send json as the value of message it will not work. I am using a simple transaction that looks almost exactly like the documentation sample. My Transaction:
content-type: application/json;charset=UTF-8
{
"region":"us-west-2",
"accessKeyId":"MyAccessKey",
"secretAccessKey":"MySecretAccessKey",
"version":"",
"messageStructure":"json",
"subject":"Test",
"message": {"default":"mess","email":"message"},
"targetArn":"arn:aws:sns:us-west-2:977102061874:endpoint/APNS_SANDBOX/mobile_iOS_Sandbox/34ed4324e6-1119-67sd-b7dd-f413c88e4e25",
"topicArn":""
}
My result is an unexpected error sending message out.
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,73]Message: Illegal character: <d>
My service is also like the example:
<amazonsns.init>
<region>{$ctx:region}</region>
<accessKeyId>{$ctx:accessKeyId}</accessKeyId>
<secretAccessKey>{$ctx:secretAccessKey}</secretAccessKey>
<version>{$ctx:version}</version>
</amazonsns.init>
<amazonsns.publish>
<message>{$ctx:message}</message>
<subject>{$ctx:subject}</subject>
<messageStructure>{$ctx:messageStructure}</messageStructure>
<topicArn>{$ctx:topicArn}</topicArn>
<targetArn>{$ctx:targetArn}</targetArn>
</amazonsns.publish>
I did not expect much success but just started trying different things....I attempted xml encoding the json message and get the same message on '&'. Using wire logs I found the content type of the successful messages going to Amazon were application/x-www-form-urlencoded so I also tried url encoding and get same message on the '%'.
I'm running out of ideas. I double checked the connector documentation to make sure I did not miss anything. It does say you can use a JSON transaction for Publish and gives a sample transaction however it does not discuss anything special/different that you would need to set up in order to make this work. Is there something I am missing?
UPDATE: Can see it is using the Builder for application/x-www-form-urlencoded which is stumbling on the json. Have tried setting messageType and ContentType properties to application/json. JSON Builder is enabled. It just seems the connector wants to send it out as application/x-www-form-urlencoded, is there something I am not setting properly to tell the connector this is JSON?
UPDATE: The publish template that comes with the connector is setting the messagetype to applicaiton/x-www-form-urlencoded which is overriding any of the settings I am making in my proxy service. Going to look at changing the template in the connector to use a different messagetype and/or allow me to set it in the proxy dynamically then will be trying again.
Joe
We have created a public JIRA for this issue. Please follow that.
You need to enable message builders for the content types you are sending. make sure following is done.
Enable relevent Message builder for each content-type.
< messageBuilder contentType="application/json"
class="org.apache.synapse.commons.json.JsonStreamBuilder"/>
Make sure Content-Type header property is parsing with the message.
Make sure your Json is wellformed.
I have a scenario in one of my Service Broker conversation configurations, which looks like this:
one message type, which is sent by initiator only (VALIDATION = WELL_FORMED_XML, no XSD)
one contract with this message type
both deployed on the initiator and target side (remote machines)
Occasionally I find Service Broker system error messages in the target queue like this:
<Error xmlns="http://schemas.microsoft.com/SQL/ServiceBroker/Error"><Code>-9616</Code><Description>A message of type 'here_is_the_name' was received and failed XML validation. XML parsing: line 1, character 547, illegal xml character This occurred in the message with Conversation ID 'here_is_the_guid', Initiator: 1, and Message sequence number: 0.</Description</Error>
I looked at Remus Rusanu's blog post and he states that:
This system error is sent to a conversation that has sent a message type marked as conforming to a certain XML schema but the payload has failed to pass the XML validation for the said schema
In my case there is no XML schema involved and I was trying to reproduce this case in my dev env using the same SQL Server versions and I was unable to do it.
I would like to know is it possible to receive this system error message although I'm not using XSD schema ? If so, when can it happen, what is the scenario where Service Broker generates error like above?
The message clearly says "XML parsing: line 1, character 547, illegal xml character" so in my opinion it has nothing to do with the schema validation.
Can it be that the transport level is encountering some problems (TCP errors) and that is why Service Broker is generating this error message ?
Message validation occurs on enqueue the message in the target queue, not on SEND. Message type validation (NONE, XML, XDS) is provided to protect your application. Validating during SEND is not enough, as a malicious application can send a message w/o using Service Broker ( a wire protocol simulator). Since validation during enqueue is mandatory, adding validation during SEND would add CPU burden for little value.
So what that means is the your SEND side application is sending invalid XML, and this gets caught on the target side. The wording on my blog is poorly chosen, I should had been more explicit that the validation can fail a schema (if specified) or it can fail the well formed XML test.
Can you post the message body you're sending?
I am running through this tutorial http://learn.knockoutjs.com/#/?tutorial=webmail
I have completed it and now am trying to run on my local machine
I have taken the code from here http://learn.knockoutjs.com/WebmailExampleStandalone.html but when I put it on my local machine I get this error.
Timestamp: 7/11/2012 4:24:41 PM Error: Unable to parse bindings.
Message: ReferenceError: mails is not defined; Bindings value:
foreach: mails Source File: url/knockout/js/knockout-2.2.0.js Line: 57
The way I downloaded the JSON file was to go to learn.knockoutjs.com/knockout/mail?folder=Inbox or learn.knockoutjs.com/knockout/mail?folder=Achive depending which folder you are are on.
I just went to learn.knockoutjs.com/mail?folder=Archive and downloaded that but that saves a file called mail with no extension.
I can understand why the the other sections (except inbox doesn't work as I don't have those JSON files) but why doesn't the mail work in the first screen?
I had the same issue. The problem was that the ajax call needs to have a response header of "application/json" type in order to properly set the returned data. I'm using php so i just added header('Content-Type: application/json; charset=utf-8'); before i echoed out the json data and everything worked.