Does any one know how to get attachment from System.ServiceModel.Channels.Message?
When client requests from the server, and server is returning a xop element with attachment in the response. But I don't know how to get the attachment from the Message obj returned from the service call.
I don't fully understand all the circumstances, but there are several options the first is to use appropriate message encoder in binding, for example CustomBinding with MtomMessageEncodingBindingElement element. In that case, XmlDictionaryReader returned by Message.GetReaderAtBodyContents() will automatically replace xop:Include elements by corresponding attachment. In case, if there are needs to manipulate attachments at lower level, or in case if non-MTOM encoding is used, you will need to write appropriate message encoder that will meets you requirements.
Related
I am getting some attributes in an API but all getting lost after an HTTP request connector in mule4.
why is it happening?
Look in the connector's configuration properties -> advanced tab for the connector configuration (in this case the HTTP connector's "request" operation) and you'll find a target variable and target value. If you fill in the target with a name - this does an enrichment to avoid overwriting the Mule message. If you leave it blank (the default) it will save the message (attributes, payload) over the top of the existing one - which is what you're seeing now. This mirrors the old mule 3 functionality, but sometimes you want it to leave what you have there alone.
So for the target value you get to pick exactly what gets saved.. If you want just payload: put that in. If you want both payload and attributes - I'd use "message" as that will mean you get both payload and attributes saved in the variable. Of course you may not want as much saved, so feel free to put in whatever dataweave expression you like - so you could even create something with bits from anywhere like:
{
statusCode: attributes.statusCode,
headers: attributes.headers,
payload: payload
}
A connector operation may replace the attributes with those of the operation. If you need to preserve the previous attributes you need to save them to a variable.
This is a default behaviour of MuleSoft. Whenever request crosses to transport barrier it losses existing attributes. You need to preserve attribute before HTTP Request.
A parse server cloud function is defined via
Parse.Cloud.define("hello", function(request, response) {..});
on the response, I can call response.success(X) and response.error(Y), and that sets the http response code and the body of the response.
But how do I define a different code, like created (201)?
And how do I set the headers of the response?
thanks, Tim
You are allowed to return any valid JSON from response.success(). Therefore, you could create an object with fields such as code, message, and value, so you can set the code, give it a string descriptor, and pass back the value you normally would, if there is one. This seems to accomplish what you need, though you will have to keep track of those codes across your platforms. I recommend looking up standard http response codes and make sure you don't overlap with any standards.
I am totally new to Parasoft virtualize. I created a virtual asset and added three fields in my data source correlation, My request xml has 4 fields. I am getting this error after processing the request.
<Reason>Failed to respond to incoming message using data source row correlation</Reason>
<Details>Values in incoming message did not match values in the data source "GetSubscriptionOperationsRequest"</Details>
Any suggestions on what might be the problem here?
The message which you are getting explains your problem.
The virtual asset cannot correlate your request with data in your data source to build response.
Try to send request with one of the values from column used for Datasource's corelation in your responder.
That value should be in request's filed used by correlation.
Maybe you should try to add catch all responder to see if you have correct corelation between incoming requests and your responder.
You can also ask Parasoft's technical support for help.
For reasons outlined here I need to review a set values from they querystring or formdata before each request (so I can perform some authentication). The keys are the same each time and should be present in each request, however they will be located in the querystring for GET requests, and in the formdata for POST and others
As this is for authentication purposes, this needs to run before the request; At the moment I am using a MessageHandler.
I can work out whether I should be reading the querystring or formdata based on the method, and when it's a GET I can read the querystring OK using Request.GetQueryNameValuePairs(); however the problem is reading the formdata when it's a POST.
I can get the formdata using Request.Content.ReadAsFormDataAsync(), however formdata can only be read once, and when I read it here it is no longer available for the request (i.e. my controller actions get null models)
What is the most appropriate way to consistently and non-intrusively read querystring and/or formdata from a request before it gets to the request logic?
Regarding your question of which place would be better, in this case i believe the AuthorizationFilters to be better than a message handler, but either way i see that the problem is related to reading the body multiple times.
After doing "Request.Content.ReadAsFormDataAsync()" in your message handler, Can you try doing the following?
Stream requestBufferedStream = Request.Content.ReadAsStreamAsync().Result;
requestBufferedStream.Position = 0; //resetting to 0 as ReadAsFormDataAsync might have read the entire stream and position would be at the end of the stream causing no bytes to be read during parameter binding and you are seeing null values.
note: The ability of a request's content to be read single time only or multiple times depends on the host's buffer policy. By default, the host's buffer policy is set as always Buffered. In this case, you will be able to reset the position back to 0. However, if you explicitly make the policy to be Streamed, then you cannot reset back to 0.
What about using ActionFilterAtrributes?
this code worked well for me
public HttpResponseMessage AddEditCheck(Check check)
{
var request= ((System.Web.HttpContextWrapper)Request.Properties.ToList<KeyValuePair<string, object>>().First().Value).Request;
var i = request.Form["txtCheckDate"];
return Request.CreateResponse(HttpStatusCode.Ok);
}
I am writing a WCF client to a SOAP service that returns a mime multi-part result with binary data (actually, a PDF file). It uses a custom message encoder.
The service doesn't seem to mind if I make the request a single-part format, so I am able to get a result back. There are two problems with the result from what I can see:
It only seems to return the first part of the multi-part message.
The data I get back cannot be decoded by my custom encoder.
I have tried utilizing MTOM binding, but that messes up the request. It fails to add the "boundary" parameter in the content-type, so the server cannot understand the request.
I think what I want is a basic text SOAP request, but a response decoded MTOM-style. I have no idea how to set that up, however.
The closest solution I have found is this: http://blogs.msdn.com/b/carlosfigueira/archive/2011/02/16/using-mtom-in-a-wcf-custom-encoder.aspx
But it seems like a very invasive change to my project.
I figured this out. First of all, I was incorrect when I said that I was only getting the first part of the multi-part message using the MTOM encoder; I was getting the whole thing. I was looking at it in the debugger and the bottom must have gotten clipped in the debug viewer. Chalk it up to my inexperience manually looking at and deciphering multi-part messages.
To the second point, all I had to do was use the MTOM encoder when the Content-Type was multipart/related and everything worked just fine. If you read the referenced article above, it's all about dynamically detecting whether the message is multipart or regular text, and choosing the proper encoder based on that. Essentially, it's a custom encoder that has both a text encoder and MTOM encoder built into it, and switches back and forth based on the content-type of the incoming message.
Our project requires some post processing of the response message before it's handed off to the main program logic. So, we get the incoming SOAP content as an XML string, and do some XML manipulation on it.
This is a slight departure from the solution recommended in the article. All that's required in the article's solution is reading the message using the right encoder into a System.ServiceModel.Channels.Message, and returning that. In our solution, we need to interrupt this process and do the post-processing.
To do that, implement the following in your custom encoder:
public override Message ReadMessage(ArraySegment<byte> buffer, BufferManager bufferManager, string contentType)
{
//First, get the incoming message as a byte array
var messageData = new byte[buffer.Count];
Array.Copy(buffer.Array, buffer.Offset, messageData, 0, messageData.Length);
bufferManager.ReturnBuffer(buffer.Array);
//Now convert it into a string for post-processing. Look at the content-type to determine which encoder to use.
string stringResult;
if (contentType != null && contentType.Contains("multipart/related"))
{
Message unprocessedMessageResult = this.mtomEncoder.ReadMessage(buffer, bufferManager, contentType);
stringResult = unprocessedMessageResult.ToString();
}
else {
//If it's not a multi-part message, the byte array already has the complete content, and it simply needs to be converted to a string
stringResult = Encoding.UTF8.GetString(messageData);
}
Message processedMessageResult = functionToDoPostProccessing(stringResult);
return processedMessageResult;
}