If I change a property of an OData entity to an invalid value (SAPUI5 client) and send that value to SAP Gateway Server using submitChanges I got the following message in the log file:
Service returned messages for entities that were not requested. This
might lead to wrong message processing and loss of messages
Now I would expect that the callback for "error" would be called but it is always "success".
Inside the callback for success I have a list of responses (in this case with an error).
Now I am asking me, why the error callback is not called?
I assume because the overall batch response is most of the time "OK" also if one request of the batch contains an error?
So do I have to implement error handling in the success callback? Or should the server send an overall error response?
I am using SAPUI5 1.28.15 (with 1.30.6 at least the cited message seems to be removed) and switched batch mode to "on" (if batch mode is off, callback will not be called!).
Related
I have an application created using Micronaut, Kotlin & Project Reactor.
I have two get api calls inside the application using ReactorHttpClient.
API1 Say getCurrentPayment this can give some 4xx errors or in success case a Mono<CurrentPayment>
API2 Say getPaymentHistory this can give some 4xx errors or in success case a Mono<PaymentHistory>
I am building a function which combines these to a Payment Object. Requirement is that if one of the api gives 200 , the combined object should have the success response with respective content.
If both failed, then only, I could respond with an error from either of them.
I tried with zip operator, but it fails if any of the one pipeline error out.
How can I combine these 2 streams such that error in either of stream should not affect the combined one and only combined one should fail if both stream has error?
I am using the Twitter API's Search Tweets endpoint (https://developer.twitter.com/en/docs/tweets/search/api-reference/get-search-tweets) to search for tweets on a particular topic. My application is written in Java and uses Twitter4j. I follow the guidelines (i.e. no more than 180 calls per minute and no more than 500 characters per query) however I do have a test case that has 50 word exclusions (so the total character count is 397). My test program also runs 100 such searches in rapid succession though, like I said, I observe the rate limits strictly.
The odd behavior I'm seeing is that the test runs fine and gets results initially, but after an arbitrary period of time, I start getting the following error:
Message: Missing or invalid url parameter. 403:The request is understood, but it has been refused. An accompanying error message will explain why. This code is used when requests are being denied due to update limits (https://support.twitter.com/articles/15364-about-twitter-limits-update-api-dm-and-following).
message - Missing or invalid url parameter.
code - 195
The error message confuses me because I'm not trying to perform any of the update actions listed in the link provided. I'm just searching tweets. I'm also not sure what "missing or invalid url parameter" means. Is a query parameter missing from my request? The only required parameter is the query itself which I am definitely passing. The url is definitely correct unless Twitter4j is generating incorrect urls. So what does this message mean?
When I stop and restart the search (i.e. the max_id and since_id values get reset to -1, the searches start working again...for a while. As far as I know, nothing else about the search changes when it is restarted. Just those two ids.
I would like to be able to catch messages going to my GenServer's handle_info in tests, to check those are what I intend to.
1/ Is there a way to print somehow every message coming through?
2/ Using assert_receive is there a way to catch those messages? Should I set the assert_receive before or after the call to the external service that will result in the handle_info trigger? What syntax should I use?
I tried many combinations of assert_receive and I tried a receive do... to try and display messages getting in, with no success.
Both ExUnit.Assertions.assert_receive/3 and ExUnit.Assertions.assert_received/2 do assert messages coming into the current process’ mailbox. The former is to be called either before or after the message was actually sent:
Asserts that a message matching pattern was or is going to be received within the timeout period, specified in milliseconds.
the latter is to be called after:
Asserts that a message matching pattern was received and is in the current process’ mailbox.
That said, both are unlikely a good fit to test the existing GenServer. Messages are to arrive at the GenServer’s messagebox, this functionality is provided by OTP and you should not test it. If you need to log messages, add a call to Logger.log/3 to the handle_info/2 and check the log actually happens with ExUnit.CaptureLog.capture_log/2. If it performs some action upon message arrival, test this action.
In general, you should test your code, not OTP.
Here is my requirement: I receive a request to validate some data/records. Records would be sent to the SQS queue per each request for further processing by another service/component. The message structure looks like this:
messageId: //a unique message id
requestId: //request id common between all messages/records for that request
record_body: {//key-value pairs}
Everything works fine. Now I want to figure out when all messages with the same request id have been read from the queue (I.e. there is no more message for that request id).
The idea that I have is to write each message/record to the database upon each read and then have another scheduled service that can be triggered (by cloudwatch) to check the number of records for each request and finally update the status of the request to complete if the number of records in the database are equal to the number of records in the original request.
I just want to share this to see if anybody else had this kind of requirement and how they approached it!
How about this ?
Include the number of requests and current request to the queue. Make sure the request goes to the queue in the same order.
Example - You have 4 requests for requestId - abc
You will send each request with values included (1:4) (2:4) (3:4) (4:4) in the order to the queue.
This way when you are reading from the queue you will read (4:4) last and you will know you have processed all the 4.
Another way to do is include total number of requests in the message in every message and while processing each message check whether it matches the original one as you have total in your message now. (by querying the database).
I have a backout queue for my queue manager.
I want to build a message flow which will read this queue and if any message comes to the queue it should take the message and wrap it in a specially formatted XML message and put it in the normal exception queue which gets the handled exceptions.
But, the message coming to the backout queue can be in any format and I have to make an xml where that message is going be a field.
So, what could be the best settings for my flow(Regarding MQMD properties like CCSID, format etc) and which parser should I use (DFDL or BLOB or MRM)?
Kindly advice.
Since you don't know what kind of message arrived to backout queue, you should not parse it with specific parsers (like XMLNSC etc). Probably the more generic params you will set on MQInput, the better you will do further down the flow to determine what's inside the message.
So, I would start with default Message domain (BLOB) and leave other params untouched as well. Connect some logging node (e.g. Trace node) to Catch and Failure terminals. Connect Out terminal to a Compute node which includes ESQL to determine error type and decide on further actions (e.g. route to label). Then in each label decide what part of the message should be mapped to final exception message and to the mapping.
If you need those MQMD properties of the message currently in backout queue in your resulting message, just extract the values and put/concatenate/whatever to resulting message XML part. I don't think you should copy MQMD (and other) headers to result message as is, because these might be the reason why original message got into backout queue and your resulting message will get there again. Construct resulting message headers from scratch.
If something bad happens while doing these transformations, you will see the problem in Trace. Then modify error handling logic appropriately to avoid mishandling in the future.