I use #Query and #Body together,but the server can't receive Body'datas.Why?
#POST("http:XXXXXXXreceive_data.json")
Observable<HttpResponse<List<String>>> uploadMultipleTypeFile(#Query("token") String token,
#Body MyBody myBody);
The #Body annotation defines a single request body .
That mean if you are using #body it should be the only parameter.It is helpful when you have already a JsonObject and you want to send it as it with you api call.
Another way is, you can convert object to json String using Gson library and send it as a JSON string.
Related
I have an Azure Custom Connector to a SOAP API that is configured with SOAP to REST. One of the methods have datetime as input:
I am genereting the DateTime with the following expression:
formatDateTime(addDays(utcNow(), -1), 's')
With the following raw input from Logic Apps, I get datetime format exception
{
"method": "post",
"path": "/MethodWithDates",
"retryPolicy": {
"type": "None"
},
"body": {
"MethodWithDates": {
"timefrom": "2019-03-18T15:59:03",
"timeto": "2019-03-19T15:59:03"
}
}
Errormessage from API:
The value '3/18/2019 3:59:03 PM' cannot be parsed as the type 'DateTime'.'
Notice how the datetime format has changed from raw output to recieved in the API. This leads me to believe the custom connector somehow changes the time format.
If I call the same endpoint with SOAP UI with the following SOAP request I get correct response. Notice the Datetime format is same as in RAW input from Logic app:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
<soapenv:Header/>
<soapenv:Body>
<tem:MethodWithDates>
<tem:timefrom>2019-03-18T15:13:31</tem:timefrom>
<tem:timeto>2019-03-19T15:13:31</tem:timeto>
</tem:MethodWithDates>
</soapenv:Body>
</soapenv:Envelope>
Interestingly, this seems only to happen for the "s" format specifier, if I format the value in any other way it is passed through in the format I specify. I still get an error in the API as its a WCF API and it seems to require the "s" format.
I can reproduce the same error when SOAP service has a Datetime input which I believe is not parsing correctly.
I am able to make this work by changing the input Datetime fields in Soap Service to string.
Non Working SOAP Service code:
public string GetDaysBetweenDates(DateTime timefrom, DateTime timeto)
{
double value = (timeto - timefrom).TotalDays;
return string.Format("Difference is: {0}", value);
}
Working WSDL Code
public string GetDaysBetweenDates(string timefrom, string timeto)
{
DateTime fromdate = DateTime.Parse(timefrom);
DateTime toDate = DateTime.Parse(timeto);
double value = (fromdate - toDate).TotalDays;
return string.Format("Difference is: {0}", value);
}
u/KetanChawda-MSFT answer is good enough, if you are able to actually change the webservice, but since this was out of our control on this one we had to do something else.
We created a separate SOAP custom connector, just for this one method with SOAP pass through.
The connector has one method, configured like this, with a default WCF API:
Url - http://hostname/Service1.svc/SoapPassThrough
Add two custom headers: Content-Type text/xml and SOAPAction methodname (ours: http://tempuri.org/IService1/methodname where tempuri is namespace
Set body to {} (Empty JSON Object)
In your logic app, you can then create a variable that contain all of the XML for a standard Soap Request. I Used SOAP UI to create a SOAP request and just pasted in the XML from the generated request. This variable can be used as body in the logic app when you consume the service.
This resource can be helpful for this: https://blogs.msdn.microsoft.com/david_burgs_blog/2018/05/03/friendlier-soap-pass-through-with-logic-app-designer-ux/
From what we have concluded, it seems like the custom connector actually sends a string datatype instead of a datetime. Creating the XML request ourself seems to fix this issue.
I want "value" from the following query string.
by doing request.query.filter i get the following
"[{\"property\":\"customerId\",\"value\":2,\"exactMatch\":true}]"
tried request.query.filter.value and request.query.filter["value"] but didn't work.
Request URL :
admin/api/login?action=get&_dc=1547652537836&filter=%5B%7B%22property%22%3A%22customerId%22%2C%22value%22%3A2%2C%22exactMatch%22%3Atrue%7D%5D
the query string seems to be a JSON string. so the first thing you have to do is convert it to json object to access it.
const query = "[{\"property\":\"customerId\",\"value\":2,\"exactMatch\":true}]";
const json = JSON.parse(query);
now you can access it with
json[0].value
My JSON is:
body =
{
"session_id":"45470003-6b84-4a2b-bf35-e850d1e2df8b",
"message":"Thanks for calling service desk, may I know the store number you are calling from?",
"callstatus":"InProgress",
"intent":"",
"responseStatusCode":null,
"responseStatusMsg":null,
"context":"getstorenumber"
}
How to get message value using Node js? Please let me know after testing.
i tried body.message and body['message'] and also body[0]['message']. I am always getting "undefined"
#Chris comment, since the problem is sorted out, Adding the answer to all members for future ref.
From node.js result, body is taken as JSON string, using JSON.parse.body converted to json object.
body =
{
"session_id":"45470003-6b84-4a2b-bf35-e850d1e2df8b",
"message":"Thanks for calling service desk, may I know the store number you are calling from?",
"callstatus":"InProgress",
"intent":"",
"responseStatusCode":null,
"responseStatusMsg":null,
"context":"getstorenumber"
}
JSON.parse.body
console.log(body.message);
If I add parameters to the url in the Objective-C code, is it possible to read it from the client?
Example:
- (NSURL *)serverURL {
return [NSURL URLWithString:#"http://rap.eclipsesource.com/demo?parametername=value"];
}
In the Client-JavaCode I can get the value of the parameter like this:
String parameter = RWT.getRequest().getParameter("parametername");
If I access the "app" with the browser I get a value for the parameter. If I access the app with the TabrisClient the value is null.
Is there a way to get the value also in the TabrisClient?
Update:
The server does not directly extract the query string from the request URL, but from the first JSON message received from the client. The web client provides the parameter queryString in the head part of the first UI request. Example:
{
"head": {
"queryString": "foo=23&bar=42",
"requestCounter": ...
},
"operations": [
...
]
}
You would have to fake this behavior in your Tabris client. I'd suggest that you file an issue against Tabris to provide API to set startup parameters.
Original answer:
If you're going to hard-code the parameter in the tabris client anyway, you could set the variable based on the connected client:
parameter = (RWT.getClient() instanceof WebClient)
? RWT.getRequest.getParameter("parametername")
: "tabris-value";
BTW, access to request parameters is going to change in RAP 3.0. Instead of RWT.getRequest().getParameter(), a ClientService will provide the parameters.
In the Youtube API, there is the power to request a "partial feed".
This allows the app developer to tailor the size and sturcture of the data returned, by specifying which "fields" to return.
i.e. GET api/person/1?fields=(id,email) would return a DTO containing only the id and the email fields, not the whole person response.
How would you attempt this using ServiceStack? Is there some way to attach a callback to the serialiser to control which properties to include in the response object?
From my experience servicestack only returns fields that actually has data. If my experience is correct then all you would need to do is figure out the best way to architect the request so that it is asking for specific data to return, this way you would only populate the response with data requested thus servicestack would only return that.
I implemented this for an API that only returns JSON.
First I created two structs to (de)serialize and interpret the "fields" query argument recursive syntax:
FieldSelector, which specifies a field and possibly its children FieldSelection enclosed between parenthesis;
FieldsSelection, which is a comma-separated list of FieldSelector.
I've used structs instead of classes because, AFAIK, you can't override class (de)serialization from/to URLs in ServiceStack. With structs you can do it by overriding ToString (serializer) and providing a constructor accepting a string as parameter (deserializer).
Then you include this on every request DTO that returns JSON:
FieldsSelection Fields { get; set; }
On a custom ServiceRunner<T>.OnAfterExecute you serialize the response DTO to JSON, parse it with ServiceStack.Text's JsonObject and apply the fields selection recursively with a method like this:
private static JsonObject Apply(this JsonObject json, FieldsSelection fieldMask)
{
IEnumerable<string> keysToRemove = json.Keys.ToList().Except(fieldMask.Keys);
foreach (var key in keysToRemove)
json.Remove(key);
foreach (var selector in fieldMask.Selectors.Values.Where(s => s.HasSubFieldsSelection))
{
var field = json[selector.Field];
if (field == null)
continue;
switch (field[0])
{
case '{':
json[selector.Field] = Apply(json.Object(selector.Field), selector.SubFieldsSelection).ToJson();
break;
case '[':
var itensArray = json.ArrayObjects(selector.Field);
for (int i = 0; i < itensArray.Count; i++)
itensArray[i] = Apply(itensArray[i], selector.SubFieldsSelection);
json[selector.Field] = itensArray.ToJson();
break;
default:
throw new ArgumentException("Selection incompatible with object structure");
}
}
return json;
}
Then you return the result as your response DTO. I've also implemented negative fields selectors (fields=-foo selects all DTO fields except foo), but you get the idea.
Look at ServiceStack.Text.JsConfig properties, they have all the hooks and customizations ServiceStack's text serializers support. Specifically the hooks that allow you to custom deserialization are:
JsConfig<T>.DeserializeFn
JsConfig<T>.RawDeSerializeFn
JsConfig<T>.OnDeserializedFn
We were able to implement said filtering by adding custom service runner and using some reflection in it to construct ExpandoObject with required field set by response DTO. See this for more info on service runners.