We have a requirement to call one of the back end service with call mediator from default fault sequence in case of times outs in normal end points. Do we always need to exit from the fault sequence in case of any time outs OR we can have a logic to call back end services from fault sequence.
Well, your use case is related to guaranteed delivery. I suggest you to use Message store and message processor combination to achieve this. There you can specify retry attempts. You simply need to use store mediator to store the message into a JMS store to which Scheduled Message Forwarding Processor is listening. The message processor will then send the message to the endpoint and send the response back. Also the message processor will ensure the guaranteed delivery too. You may find more information here. If you need to have a deep dive in to the message processor please refer my blog post at [2].
[1] https://docs.wso2.com/display/ESB490/Sample+702%3A+Introduction+to+Message+Forwarding+Processor
[2] http://ravindraranwala.blogspot.com/2015/09/message-processor-coordination-support.html
Related
I am currently creating some custom flows, sending back and forth some data through the session. I noticed that in some cases (for example if a responder flow has a session.receive still unanswered when the initiating flow finishes), no exceptions are thrown and everything works smoothly, without even a warn log. Is there a way to force the check of send/receive completeness?
If you can provide some log file to demonstrate your use case would be better.
Send & Receive is typically a one-direction communication, one sends and one receives. If you are looking for a confirm receive, you can try to use method sendAndReceive, which
Serializes and queues the given payload object for sending to the counterparty.
Suspends until a response is received, which must be of the given R type.
Receive method itself is a blocking method, so if your flow successfully finishes. it means the receive method successfully receive what it is looking for.
But again, it would be much better if you can share your log and the elaborate on your questions a bit.
When there is a "FAULT" and "max.delivery.attempts" processes the configured number of times and even then the process continues in "FAULT" logo in the following section "Message Processor Turns" without manual intervention it activates again? The fact that the "Message Processor" DISABLED can not impact the reading of new messages in JMS queue.
Since the Message store and process story implemented in the way to served as First Come First Out basis it is not possible to skip the message that got fault and continue the message flow.
Nevertheless up coming release has a new improvement where you can drop the message out from the queue after x number of fail attempts. Having said that, it is not good practice while you do the schedule and process.
To understand further about Message-stores and Message-processors read on the given article
In order to avoid this situation you can use the Sampling processor and send the message to back-end. Sample process will immediately remove it from the queue and process further. If the delivery of the message is failed or if you find fault you can re added in to store in Fault sequence.
The documentation isn't very clear on the default function of a mediation sequence. I understand that it is possible to define in and out mediators to perform a set of mediators on messages that are incoming or outgoing.
However, what happens if I have neither of these defined? Does the sequence then accept and perform its mediators on ALL messages? If this is the case, is it therefore possible for a sequence to get stuck in an infinite loop if it sends out to a service and receives the response, causing it to send it out to that service again.
As an aside to this, is it recommended to always explicitly declare in/out mediators in every sequence?
Basically when you are using a sequences inside ESB , you will use as receiving sequence or as target sequence from a proxy.
1) Use as receiving sequence :
When you are using as receiving sequence you will be doing some kind of mediation on the response message to the ESB, and then continue with rest of the proxy meditations (not define any IN/OUT path, it just proceed with current direction of the message).There is no IN or OUT, so it will just continue with current direct where it came. See the sample below
http://docs.wso2.org/display/ESB470/Sample+156:+Service+Integration+with+specifying+the+receiving+sequence
2) Use as a proxy target sequence:
Here you can use your sequence as proxy target , so you can define IN path and OUT ,if you need to do some mediation separately inside sequence IN and OUT paths. But if you don't define OUT then it will proceed with the default ESB OUT path and response go back to client. There is no infinite loop as you assume.
http://docs.wso2.org/display/ESB470/Sample+381%3A+Class+Mediator+to+CBR+Binary+Messages
So it is your choice to put IN or OUT for sequence based on your requirement.
I made a call to a third party web service and get back an ESOAPHTTPException with a message in this format:
Cryptic message here - URL: http://webserviceurl - SOAPAction: performWithArgList
Now the support personnel for this web service has asked for the full SOAP response. Normally, I would attach an event handler to THTTPRIO.OnAfterExecute and simply store the content of the stream I receive as parameter.
But since Delphi raises the exception, that event handler doesn't execute. I understand that the exception may in fact mean that the service had failed in some catastrophic way, but there should still be some kind of response (not a timeout error).
Is there some other method I can use to trap the response before Delphi turns it into an exception?
For an ERemotableException-based exception you'd want to look at the OnAfterExecute event as it represents a fault sent back by the Service... but for ESOAPHTTPException (your case) you'll want to handle the OnWinInetError event ( http://docwiki.embarcadero.com/VCL/en/SOAPHTTPTrans.THTTPReqResp.OnWinInetError).
D2010 introduced a bug in the SOAP HTTP handling. The typical symptom is that it would miss HTTP failures (such as when the Server is busy). So maybe that's not the issue you're running into but without knowing the exact error code or message you're seeing, one cannot tell. You can find more details here: https://forums.embarcadero.com/message.jspa?messageID=304898&tstart=0
For example, if you're getting the error about 'Handle is in the wrong state', the issue mentioned above is the culprit. It means that the 'Send' failed but the runtime happily proceeded to read a response. You can find out more about that one from this thread: https://forums.embarcadero.com/message.jspa?messageID=307048.
So you should handle OnWinInetError and grab the error code (LastError param). That's probably key to understanding the failure.
Cheers,
Bruneau
Yes, you can use the RIO event to examine the response before it is deserialized.
OnAfterExecute
You'll get the response as a stream, which you can convert to a string. Then you can examine for bad things like exceptions, beign totally empty, or starting with '', which usually (in my case) indicates that the service isn't up.
I would open the source for SOAPHTTPTrans and put a break point inside THTTPReqResp.Check(), just inside the "if error". When you hit the breakpoint, you'll have more of an idea what's wrong. Look at the call stack to see how you got here. It's probably something going wrong with your reqest being created and sent. If it's during the send, then it's likely not ever going out on the network so you won't see it with WireShark, Fiddler, or SoapUI.
IMO, functions like Check() should have an extra parameter for CallerLocation, so that instead of calling this:
Check(not Assigned(Request), False);
you'd call this:
Check(not Assigned(Request), False, 'THTTPReqResp.SendGet');
and Check would append CallerLocation to the error message, and you'd know (a lot) more about what's going on.
We are building a REST service that will take about 5 minutes to execute. It will be only called a few times a day by an internal app. Is there an issue using a REST (ie: HTTP) request that takes 5 minutes to complete?
Do we have to worry about timeouts? Should we be starting the request in a separate thread on the server and have the client poll for the status?
This is one approach.
Create a new request to perform ProcessXYZ
POST /ProcessXYZRequests
201-Created
Location: /ProcessXYZRequest/987
If you want to see the current status of the request:
GET /ProcessXYZRequest/987
<ProcessXYZRequest Id="987">
<Status>In progress</Status>
<Cancel method="DELETE" href="/ProcessXYZRequest/987"/>
</ProcessXYZRequest>
when the request is finished you would see something like
GET /ProcessXYZRequest/987
<ProcessXYZRequest>
<Status>Completed</Status>
<Results href="/ProcessXYZRequest/Results"/>
</ProcessXYZRequest>
Using this approach you can easily imagine what the following requests would give
GET /ProcessXYZRequests/Pending
GET /ProcessXYZRequests/Completed
GET /ProcessXYZRequests/Failed
GET /ProcessXYZRequests/Today
Assuming that you can configure HTTP timeouts using whatever framework you choose, then you could request via a GET and just hang for 5 mins.
However it may be more flexible to initiate an execution via a POST, get a receipt (a number/id whatever), and then perform a GET using that 5 mins later (and perhaps retry given that your procedure won't take exactly 5 mins every time). If the request is still ongoing then return an appropriate HTTP error code (404 perhaps, but what would you return for a GET with a non-existant receipt?), or return the results if available.
As Brian Agnew points out, 5 minutes is entirely manageable, if somewhat wasteful of resources, if one can control timeout settings. Otherwise, at least two requests must be made: The first to get the result-producing process rolling, and the second (and third, fourth, etc., if the result takes longer than expected to compile) to poll for the result.
Brian Agnew and Darrel Miller both suggest similar approaches for the two(+)-step approach: POST a request to a factory endpoint, starting a job on the server, and later GET the result from the returned result endpoint.
While the above is a very common solution, and indeed adheres to the letter of the REST constraints, it smells very much of RPC. That is, rather than saying, "provide me a representation of this resource", it says "run this job" (RPC) and then "provide me a representation of the resource that is the result of running the job" (REST). EDIT: I'm speaking very loosely here. To be clear, none of this explicitly defies the REST constraints, but it does very much resemble dressing up a non-RESTful approach in REST's clothing, losing out on its benefits (e.g. caching, idempotency) in the process.
As such, I would rather suggest that when the client first attempts to GET the resource, the server should respond with 202 "Accepted" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3), perhaps with "try back in 5 minutes" somewhere in the response entity. Thereafter, the client can poll the same endpoint to GET the result, if available (otherwise return another 202, and try again later).
Some additional benefits of this approach are that single-use resources (such as jobs) are not unnecessarily created, two separate endpoints need not be queried (factory and result), and likewise the second endpoint need not be determined from parsing the response from the first, thus simpler. Moreover, results can be cached, "for free" (code-wise). Set the cache expiration time in the result header according to how long the results are "valid", in some sense, for your problem domain.
I wish I could call this a textbook example of a "resource-oriented" approach, but, perhaps ironically, Chapter 8 of "RESTful Web Services" suggests the two-endpoint, factory approach. Go figure.
If you control both ends, then you can do whatever you want. E.g. browsers tend to launch HTTP requests with "connection close" headers so you are left with fewer options ;-)
Bear in mind that if you've got some NAT/Firewalls in between you might have some drop connections if they are inactive for some time.
Could I suggest registering a "callback" procedure? The client issues the request with a "callback end-point" to the server, gets a "ticket". Once the server finishes, it "callbacks" the client... or the client can check the request's status through the ticket identifier.