How can I map SOAP Fault to REST JSON object in API Connect?
I am handling SOAP Faults by check "Stop on Error" in my Invoke component, however, I don´t know how to get fault body and set in a JSON object in my message.body, for instance
I found out how to solve this issue.
In my case, my problem was that the invoke´s variable output exposed me its JSON body as a NodeList XML, so I couldn´t retrieve any information of this.
I got this variable and transformed it to XML in a gatewayscript
var nodeList = apim.getvariable('<responseServiceVariable>.body');
apim.setvariable('message.headers.content-type', 'application/xml')
apim.setvariable('message.body', nodeList);
After that, I used the XML-to-JSON component.
And then, I transformed response with other gatewayscript
apim.readInputAsJSON(function (error, json) {
if (error) {}
var jsonString = JSON.stringify(json)
.replace(/\$/g,'value');
var jsonReplaced = JSON.parse(jsonString);
var envelope = jsonReplaced['s:Envelope'];
var body = envelope['s:Body'];
var fault = body['s:Fault'];
var faultstring = fault['faultstring'];
var moreInformation = faultstring['value'];
var httpMessage = "My httpMessage"
var error = {"httpCode": 400, "httpMessage": httpMessage, "moreInformation": moreInformation}
apim.setvariable('message.headers.content-type', 'application/json')
apim.setvariable('message.status.code', 400);
apim.setvariable('message.body', error);
});
Related
I try to get a Base64 from a image-URL in my hosted Blazor Webassambly. The URL contains a link to a picture.
using (var client = new HttpClient())
{
var bytes = await client.GetByteArrayAsync(url); // there are other methods if you want to get involved with stream processing etc
var base64String = Convert.ToBase64String(bytes);
return base64String;
}
Throws Exception:
TypeError: Failed to fetch
The Exception is thrown with any client method.
var result = await client.[X](url);
Why its impossible to make a request with he http client?
I would try it with first retrieving the link to the picture and then downloading the bytes from there.
string pictureLink = await client.GetStringAsync(url);
var base64String = Convert.ToBase64String(await client.GetByteArrayAsync(pictureLink));
So, I've created a new Azure Functions project v3 and am porting over a subset of functions from v1 that was running on 4.6.2, while retiring the rest as obsolete. Unfortunately in the change from BrokeredMessage to Message due to changing from Microsoft.ServiceBus.Messaging to Microsoft.Azure.ServiceBus the following deserialization method is now failing with:
There was an error deserializing the object of type stream. The input source is not correctly formatted.
The problem is right there in the error, but Im not sure what the correct new approach is, its a bit unclear.
Serialize
public static Message CreateBrokeredMessage(object messageObject)
{
var message = new Message(Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(messageObject)))
{
ContentType = "application/json",
Label = messageObject.GetType().Name
};
return message;
}
Deserialize
public static T ParseBrokeredMessage<T>(Message msg)
{
var body = msg.GetBody<Stream>();
var jsonContent = new StreamReader(body, true).ReadToEnd();
T updateMessage = JsonConvert.DeserializeObject<T>(jsonContent);
return updateMessage;
}
Object
var fileuploadmessage = new PlanFileUploadMessage()
{
PlanId = file.Plan_Id.Value,
UploadedAt = uploadTimeStamp,
UploadedBy = uploadUser,
FileHash = uploadedFileName,
FileName = file.Name,
BusinessUnitName = businessUnitName,
UploadedFileId = uploadedFile.Id
};
```
Message.GetBody<T>() is an extension method for messages sent using the legacy Service Bus SDK (WindowsAzure.ServiceBus package) where BrokeredMessage was populated with anything other than Stream. If your sender sends an array of bytes as you've showed, you should access it using Message.Body property.
In case your message is sent as a BrokeredMessage, the receiving code will need to select either of the methods based on some information to indicate how the message was originally sent.
I need to send messages from a .NET Core app via the Azure Service Bus to BizTalk 2013. I have configured a WCF Custom receive port on BizTalk but on receiving a message get the following error:
The adapter "WCF-Custom" raised an error message. Details "System.Xml.XmlException: The input source is not correctly formatted.
I've found examples using Windows.Azure.ServiceBus package and BrokeredMessage, but this is deprecated. I need to use Microsoft.Azure.ServiceBus and the Message object.
I've tried many ways of serializing the XML but nothing seems to work.
In short I'm creating the message like this:
var message = new Message(Encoding.UTF8.GetBytes("<message>Hello world</message>"));
Is there a way to serialize the message correctly to be received by WCF in BizTalk 2013?
I figured it out.
For anyone who needs to send messages via Azure Service Bus using Microsoft.Azure.ServiceBus Message to BizTalk 2013 WCF-Custom receive port.
var toAddress = "sb://yourbusname.servicebus.windows.net/yourqueuename";
var bodyXml = SerializeToString(yourSerializableObject); //
var soapXmlString = string.Format(#"<s:Envelope xmlns:s=""http://www.w3.org/2003/05/soap-envelope"" xmlns:a=""http://www.w3.org/2005/08/addressing""><s:Header><a:Action s:mustUnderstand=""1"">*</a:Action><a:To s:mustUnderstand=""1"">{0}</a:To></s:Header><s:Body>{1}</s:Body></s:Envelope>",
toAddress, bodyXml);
var content = Encoding.UTF8.GetBytes(soapXmlString);
var message = new Message { Body = content };
message.ContentType = "application/soap+msbin1";
This wraps the Xml in a proper SOAP format. Note the "to" embedded in the SOAP envelope is necessary (I found it didn't work using message.To).
For completeness, this is the serialization method (for clean xml):
public string SerializeToString<T>(T value)
{
var emptyNamespaces = new XmlSerializerNamespaces(new[] { XmlQualifiedName.Empty });
var serializer = new XmlSerializer(value.GetType());
var settings = new XmlWriterSettings
{
Indent = false,
OmitXmlDeclaration = true
};
using (var stream = new StringWriter())
using (var writer = XmlWriter.Create(stream, settings))
{
serializer.Serialize(writer, value, emptyNamespaces);
return stream.ToString();
}
}
I'm trying to POST a request containing JSON from a Razor Pages app to a WCF service endpoint expecting a Json WebMessageFormat and Bare BodyStyle.The JSON passes just fine via Postman, but not when I send it through http-client. Wireshark also shows some extra bytes around JSON in the http-client produced packet that are not present in the Postman packet. Wireshark also reports this as line-based text data: application/json for the Postman packet. The .Net packet is JavaScript Object Notation: application/json.
Here's my C# code to send the JSON to the WCF endpoint:
var client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:8000");
dynamic foo = new ExpandoObject();
foo.position = 1;
var content = new StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(foo), System.Text.Encoding.UTF8, "application/json");
var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:8000/WCFService/ControllerV1/PostJSON");
request.Headers.Add("cache-control", "no-cache");
request.Headers.Add("Accept", "*/*");
request.Headers.Add("Connection", "keep-alive");
request.Content = content;
try
{
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
string responseBody = await response.Content.ReadAsStringAsync();
}
catch (HttpRequestException e)
{
Console.WriteLine(e.Message);
}
And here's my WCF endpoint declaration:
[OperationContract, WebInvoke(Method="POST", RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
void PostJSON(string jsonString);
I would expect the packets to produce the same response from the server, but, what appears to be the same string produces a response 200 when the packet is built by postman and a response 400 when built by .Net. I'm clearly missing something subtle here, but I can't seem to tease it out.
There are 2 possible BodyStyle for request and response, wrapped or bare. When you specify wrapped body style the WCF service expects a valid json to be passed which in your case would be
//note that property name is case sensitive and must match service parameter name
{
"jsonString": "some value"
}
And when you specify bare format the service expects only plain string value (in case of primitive type as yours) as the request like this
"some value"
When you serialize your object like this
dynamic foo = new ExpandoObject();
foo.position = 1;
string result = JsonConvert.SerializeObject(foo);
the result contains the following json
{
"position":1
}
which corresponds to wrapped format and the service returns 400: Bad Request. All you need to do is to turn this json into valid json string value like this
"{\"position\":1}"
It can be done by repeated JsonConvert.SerializeObject call
dynamic foo = new ExpandoObject();
foo.position = 1;
string wrapped = JsonConvert.SerializeObject(foo);
string bare = JsonConvert.SerializeObject(wrapped);
var content = new StringContent(bare, System.Text.Encoding.UTF8, "application/json");
I have a WCF web service which throws exceptions when invalid data is submitted. The data is submitted via an HTTP Post using the WebClient object.
Here is the code for the web service:
[WebInvoke(UriTemplate = "update", Method = "POST")]
public JsonValue Update(HttpRequestMessage message)
{
var context = new Entities();
dynamic response = new JsonObject();
// in order to retrieve the submitted data easily, reference the data as a dynamic object
dynamic data = message.Content.ReadAs(typeof(JsonObject), new[] { new FormUrlEncodedMediaTypeFormatter() });
// retrieve the submitted data
int requestId = data.requestId;
int statusId = data.statusId;
string user = data.user;
string encryptedToken = data.token;
string notes = data.notes;
// retrieve the request with a matching Id
var request = context.Requests.Find(requestId);
// make sure the request exists
if (request == null)
throw new FaultException("The supplied requestId does not exist.");
// make sure the submitted encrypted token is valid
var token = DecryptToken(encryptedToken);
if (token == null)
throw new FaultException("Invalid security token.");
// TODO: Validate other token properties (e.g. email)?
if (!request.User.UserName.Equals(token.UserName))
throw new FaultException("Invalid security token.");
// additional logic removed ...
}
And here is the code that submits data to the web service:
// use the WebClient object to submit data to the WCF web service
using (var client = new WebClient())
{
client.Encoding = Encoding.UTF8;
// the data will be submitted in the format of a form submission
client.Headers[HttpRequestHeader.ContentType] = "application/x-www-form-urlencoded";
var data = new NameValueCollection();
// prepare the data to be submitted
data.Add("requestId", requestId.ToString());
data.Add("statusId", this.StatusId);
data.Add("token", token.ToString());
data.Add("user", this.User);
data.Add("notes", this.Notes);
// submit the data to the web service
var response = client.UploadValues(this.Address, data);
}
I keep getting an exception with message: "The remote server returned an error: (500) Internal Server Error" at client.UploadValues(this.Address, data);.
Is there a way I can make sure that more detailed information is returned to the WebClient?
Also, how can I make sure that these exceptions (in the WCF service) are logged to the EventLog? (Basically I just need to know what happened).
Take a look at HttpResponseException (namespace Microsoft.ApplicationServer.Http.Dispatcher) - they're the way where you can control the response for error cases. You can specify the status code, and you have control over the HttpResponseMessage, in which you can control the message body.
On the client side, when you call WebClient.UploadValues, wrap that call and catch a WebException. If the service returns a response with a non-successful status code (e.g., 500, 400), the Response property of the WebException will have the body, in which you can read in your client.
Another option is to use HttpClient instead of the WebClient, in which case you can simply look at the HttpResponseMessage directly.