Sending Messages as FORM Variables with the HTTP Adapter

Here's a quickie. If you want to send a message, as a FORM Variable in a HTTP request, this is what you do:

1) Set the Content Type property of the HTTP send port, to application/x-www-form-urlencoded.

2) Create a custom pipeline and plug-in a Custom Pipeline Component, that pre-pends Variable-Name= in front of the message, and url encode it. e.g: ClaimPacket=

3) Use this pipeline with your HTTP send port, and you are done!

Post a comment for a sample.

Update : Screen shot of the Content Type property:

Comments

Anonymous said…
Thanks, I was struggling with that.
September 20, 2004 4:49 PM
Anonymous said…
I can't find the ContentType property on the HTTP send port. Could someone walk me through it?
March 17, 2005 8:56 AM
Devdutt said…
Hey JT,

Added a screen shot of the location of the ContentType property. Hope that helps.
March 18, 2005 4:21 PM
Anonymous said…
Dev,

Thank you SO MUCH for having this post available. I am very thankful to you for sending me a custom pipeline component. After unsuccessfully using FixMsg from the SDK, your component saved the day! FixMsg was putting some chars between the prepend and the actual message that was causing the post to fail. Your component worked beautifully. Not only that, but it was so straightforward that I was able to easily modify it to accept additional parameters for the post variables.

Your timeliness and continued responses to me during this effort are truly appreciated. You are an asset to the development community.

I've bookmarked you as a "favorite". Keep the posts coming!

Michael
March 31, 2005 11:06 AM
Anonymous said…
This is absolutely what I need to do as I have to prepend QUERY= to the front of an xml document before HTTP POSTing it out.

Thanks for the 'Heads-Up', you've saved me some serious time here.

I was going to start out with FixMsg as well but I noticed Michael's comments. Would it be possible to also get a copy of your Pipeline component?

Keep 'em coming...
October 28, 2005 2:17 PM
Post a Comment

Popular posts from this blog

Using recursion in the In-line XSLT Template type Scripting Functoid

People using In-Line XSLT Templates in their scripting functoids often run into the need for looping, WITHOUT using an <xsl:for-each> . An example in the BizTalk context would be, if you had a comma separated string in the source schema and wanted to tokenize it into multiple destination schema elements. The following XSLT template does that for you. <xsl:template name="TokenizeCommaSepString"> <xsl:param name="stringToTokenize" /> <xsl:param name="destinationElementName" /> <xsl:if test="$stringToTokenize != ''"> <xsl:choose> <xsl:when test="contains($stringToTokenize, ',')=0"> <xsl:element name="{$destinationElementName}"> <xsl:value-of select="$stringToTokenize" /> </xsl:element> </xsl:when> <xsl:otherwise> <xsl:element name="{$destinationElementName}"> <xsl:value-of select="substring-be
Read more

Uniform Sequential Convoys in BTS 2004 using Correlation

This orchestration is a small primer if you want to implement a "Sequential Convoy " with BizTalk 2004. You would want to do this if: a) You have to force messages coming in at a particular port to correlate together and get processed by the same orchestration instance. (Correlation with multiple ports is a topic of a subsequent post) b) You want your output messages to be delivered in the same order that the orchestration got them. c) Some pipeline components you use, take one message but give out multiple messages, but you want to process these multiple messages together. For eg: the HIPAA and HL7 disassembler components. ...and probably some more scenarios that I can't think of right now. The attached orchestration correlates messages w.r.t ReceivedFileName (think about the HIPAA 835 scenario mentioned above). You can use whatever correlation parameters you desire. TIP: Whatever properties you choose to correlate the incoming messages with, make sure tha
Read more