With the default behaviour when a message is not routed the message is lost.
You could create a queue that receives all messages by using the # for the routing key in the binding. Then create a process that handles all the non routed messages. The process will have to connect to the queue and receive all messages and somehow know whether they have been routed or not. What you will need to do is call the management plugin cli to return all the bindings for an exchange. Parse that result to get you this list of the bindings for the exchange and ignore any incoming message which matches the bindings. Then you can just process the ones that never got routed in the first place. You could even read them back to another queue for a worker process to consume.
have a look at this for information on the management plugin cli.
If you prefer to use the rabbitmqctl you could use
sudo rabbitmqclt report
to get a report that would need to be parsed to get all the bindings. See here
Related
Here is an image of a common structure we have in a few of our BizTalk orchestrations:
So when we GET information from an API and the account doesn't exist, we terminate the orchestration. This works fine and I can see the orchestration doing this and terminating when it should, but what I don't understand is why do I see the suspended message from the GET in the console? Since the exception handling works, shouldn't this stop an error showing in the console?
As a way around this, I've considered using a pipeline component to check the response message, and if it contains what would be ignored, just return null in place of the message. Would this have the desired effect? I'm more interested as to why I see the suspended messages in the console.
Yes, this is a known issue with the WCF-WebHttp adapter, that has to do with the fact that it throws it back as a SOAP formatted error, but without setting the MessageType context property (see my blog post and look for Bug: BizTalk WCF-WebHttp adapter does not set the message type on error). So although the exception is thrown back at the Orchestration and can be handled there, the message is not as BizTalk does not know what type it is and it suspends.
A workaround we use is
To set Enable Routing for failed messages on the send port
To have a send port that subscribes to all the response messages from that send port using the BTS.SPName = xxxx filter, and send port sends it to a custom NULL adapter (throw the message away), and yes, your Orchestration will still get the good response as well as the exceptions.
Update the send port that handles routing errors from other send ports that we do want to go to our exception handing to exclude those send ports which we are handling via an Orchestration.
The Flag Ocp-Apim-Tracehas been set to true.
The API Response displays this information under the Trace Tab:
Trace location was not specified in the response or trace log is not
available.
Yet no traces are available. How does one resolve this?
To enable trace, you need to include "Ocp-Apim-Trace" and "Ocp-Apim-Subscription-Key" in request header.
If the API does not require subscription, you can still get admin subscription key in developer portal. This enforces that only admin can get tracing log. To get admin subscription key if you are an admin, go to Developer Portal -> Profile -> find your target API and copy the key.
The Ocp-Apim-Trace feature enables you to specify whether or not APIM should generate a trace file on blob storage.
Setting the header to 'true' within Postman for example, will give you back a HTTP Header in the response called Ocp-Apim-Trace-Location.
This will contain the URL to your trace file, which you can open in any browser.
You might want to install a plugin/extension to be able to format JSON files properly in order to make it easy to read.
Just setting the flag Ocp-Apim-Trace to true will not suffice.
One needs to set the subscription key as well as per this doc.
https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#Trace
So, for API's which do not have a subscription key, not sure how one can get the traces
I am using IBM integration toolkit
I have an application with two flows; the request flow has a json request message using http request node then the message is thrown to another flow (in another application representing a stub)through a MQ Input, compute node then MQ reply.
It then throws the message to the response flow in my application through MQ Input
I need to output the message in a json form through http reply node but in the flow it runs an exception "Message does not contain valid HTTP context information, Need return context info"
if anyone have a clue for this error and how to solve it
Thanks in advance
The problem is that your HTTP response flow does not know which request it has to respond.
In case you really need your request and response to be implemented as different flows, you have to store identifier of incoming HTTP or SOAP request somewhere, for example as a message in some dedicated queue.
In your request flow you can find identifier of request in
InputLocalEnvironment.Destination.HTTP.RequestIdentifier
or
InputLocalEnvironment.Destination.SOAP.RequestIdentifier
depending on the type of your input node.
Then, your response flow should read a message written by request flow to find a value of RequestIdentifier.
This value should be set into the LocalEnvironment of response message assembly:
OutputLocalEnvironment.Destination.HTTP.Reply.ReplyIdentifier
or
OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier
Here is IBM doc: https://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac20450_.htm#ac20450___le
When the HTTPInput node receives an input request message, it sets the local environment field Destination.HTTP.RequestIdentifier to a unique value that identifies the Web service client that sent the request. You can refer to this value, and you can save it to another location if appropriate.
For example, if you design a pair of message flows that interact with
an existing WebSphere MQ application (as described in Broker calls
existing Web service), you can save the identifier value in the
request flow, and restore it in the reply flow, to ensure that the
correct client receives the reply. If you use this technique, you must
not change the data, and you must retain the data as a BLOB.
The HTTPReply node extracts the identifier value from the local
environment tree and sets up the reply so that it is sent to the
specific client. However, if you are using an HTTPReply node in a flow
that does not have an HTTPInput node, and this field has been deleted
or set incorrectly, message BIP3143S is issued.
I have this json feed.
I am unable to load this into Appgyver
I have set the following required settings:
- parameter app_name with the correct value
- added the reuired header X-DREAMFACTORY-APPLICATION-NAME
I always get the Oops, Unable to load resource's data model. error
Anyone who has a clue?
I am not very familiar with AppGyver, but I know it's been used with DreamFactory successfully by others. You have not provided enough information, but I will attempt to give you troubleshooting steps from the DreamFactory side.
First, are you definitely authenticating and passing a valid X-DreamFactory-Session-Token header? I can tell that you don't have guest access enabled (to make calls without authentication) because when I navigate to your link I receive a 401 with "There is no valid session for the current request."
Second, what is the call you're making from AppGyver? Is it a GET to simply list resources of a DB called vlaamse_vinyl, or what?
Finally, if you are passing X-DreamFactory-Application-Name in addition to the URI parameter ?app_name=vlaamse_vinyl this is redundant. Perhaps that is preventing your call from succeeding.
I've implemented logging of all requests/responses using (in my AppHost.cs):
this.RequestFilters.Add(serviceLogFilter.LogRequest);
this.ResponseFilters.Add(serviceLogFilter.LogResponse);
During the logging of the request, I get the new ID from the logging table and put it into IHttpRequest.Items.
My question is: when an error occurs, like if the validation of the incoming data fails, or my business logic throws an Exception, is there a way I can customize the returned error to contain my log reference? Preferably by adding a JSON body to the error response. Alternatively, setting a custom HTTP header?
The idea is that my customer could give me a log reference if something unexcpected happens, and I would find his request and could easily reproduce the problem.
See this question on different ways to Handle exceptions from the old and New API.
To use the IHttpRequest.Items dictionary to pass data between request filters, services and response filters in the same request.
Also the InMemoryRollingRequestLogger implementation for the Request Logger plugin shows another way to be able to log all requests.