I am using bapi_goodsmvt_create to post in migo transaction code.
The parameter return is not returning any value when the postings are successful.
Is return supposed to return only error messages? Or both error and success messages?
That is exactly how it works, if there are no errors, the RETURN table will be empty. The FM BAPI_GOODSMVT_CREATE is well documented:
Related
I have some records in the database that may or may not have some information for a certain column, and that's OK.
If a consumer of the endpoint runs into one of these records, I'd like to return "NoContent", because, well, there's No Content for that record that we can execute on. BUT ... I'd like to give them a message why, as there are two distinct reasons.
When looking at other status codes, this works:
return Accepted("I SEE THIS STRING!");
It actually shows up in the Response Header as the field location (I think, don't make me run this project again!)
This works for say Internal Server error:
return StatusCode(500, "I SEE THIS TOO!");
But, for NoContent there is no constructor like Accepted, where you can pass an object. Also, this shows me no string whatsoever:
return StatusCode(204, "WHY CAN'T I SEE THIS STRING?!");
Help!
204 (No Content) returns an HttpResponseMessage with, well, No Content.
If you do have content to return that the user can consume (the two reasons), then you don't have a No Content scenario.
Perhaps an Ok (200) with a custom ContentNotProvided class that holds a message, which can be consumed by the client, will do the trick?
Alternatively, return a BadRequest (400) with a message.
I am working on one server that resolve GraphQL queries. I used the graphql-kotlin library: https://github.com/ExpediaDotCom/graphql-kotlin.
I defined three resolve functions(could be viewed as three fields): getxxx(arguments...), getTarget(arguments...) and getSource(arguments...).
The problem is if one of my queried field failed, I will only get the 'errors' field. All other successful executed results(data) are dropped.
If I try to catch the exception for the failed field, then I will not get the 'error' field at last.
This is the image that had exception and dropped all fetched data:
The objective is returning both the successful fetched data in 'data' field and error message for failed field in 'errors' field.
I have checked this: How to return both error and data in a graphql resolver?
If I set a field that throw one error or exception intentionally, I will only get 'errors' field at last(Like the picture above).
In addition, many websites like this:https://itnext.io/the-definitive-guide-to-handling-graphql-errors-e0c58b52b5e1 suggest we should return partial result and error message, but in my case if I meet exception, only error message would be returned.
In our example application we have two top level queries
{
onlyCake(msg: "cake")
generateNumber
}
If I run this code this will return a random number and onlyCake returns the string <3. However if I modify the input of onlyCake to something that is not the string cake I will get an error. This is expected because the field onlyCake has a directive to implement this behavior.
https://github.com/ExpediaDotCom/graphql-kotlin/blob/2961b64d6e4cceb4034aec198d667e5f965decd2/example/src/main/kotlin/com/expedia/graphql/sample/directives/CakeOnlyDirectiveWiring.kt#L18-L19
The question is though, if I want to return the data still for generateNumber can I do that and have both errors and data in the response?
The answer is it's possible but not with the current schema. The issue is that our schema for onlyCake and generateNumber are both non-nullable fields. So as a client if I see that there is a data field I should expect to see both there otherwise I would have a parsing issue in my code. This is why we can't have this behaviour with the schema as is. If you want to implement this behaviour, the schema developer needs to decide where they can return null for some response and modify the errors field appropriately with a DataFetcherExceptionHandler
Or the other option is that we support the behaviour in graphql-java to return a DataFetcherResult<T> instead of just T from the kotlin functions. See the section Returning data and errors here: https://www.graphql-java.com/documentation/v13/execution/
I have created an issue to continue this discussion with other team members: https://github.com/ExpediaDotCom/graphql-kotlin/issues/244
I'm designing a REST API using Laravel 5.1.
I'm curious is it necessary to validate query string?
https://www.example.com/users?page=1;count=20
what if user put page="abc" or count="abc"?. Should i return an error or just return empty result?
Thanks
In theory an URI is an atomic identifier, so you should return a 404 Not Found, regardless of the wrong syntax or semantics. In practice, it's better to return a 400 Bad Request and a detailed explanation of the error.
I have a question regarding to Nest1.0pr and the connection error handling. In the previous versions of Nest I was using IResponse.ConnectionStatus.Error. It seems to me that the property Error does not exist in the new version anymore. However in the documentation I found the following:
ConnectionStatus is the response as it was returned by
Elasticsearch.net. It's section on handling responses applies here as
well.
And in the very section the property Error is mentioned.
Error When a call succeeds but does not return a http status code of
200 this property will have details on the error. Read more about
error handling here
So is the recommended way to check whether the property Success is false?
TIA
This changed when NEST was refactored to use Elasticsearch.Net. Now when a request fails, you can try checking the IResponse.ConnectionStatus.OriginalException property, which will contain the actual Elasticsearch error.
I have written an adapter with a few simple procedures. In some circumstances I need to signal the caller that something went wrong. I have tried a few approaches ..
Throwing an exception: the text of the exception gets back to the caller via the onFailure callback (great), but comes wrapped in the module name and line number of the exception. TMI.
Returning an object where isSuccessful = false: this works like a charm and it's delivered to the caller via the onFailure callback.
For example:
return {
isSuccessful: false,
errors: ["No servers available"]
};
This article from IBM however explicitly warns against doing just this, though doesn't describe an alternative - can you?
Have you looked at this blog post?
https://www.ibm.com/developerworks/community/blogs/worklight/entry/handling_backend_responses_in_adapters?lang=en
The blog post details:
For invokeProcedure (client to adapter):
What does an invocation response look like?
When will isSuccessful be true?
When will isSuccessful be false?
For invokeHttp (adapter to server):
What does a backend invocation response look like?
When will isSuccessful be true?
When will isSuccessful be false?
Based on the conditions you will provide in the response to the client, you can then return errors in more clarity.