Say this is my router config
<apikit:config name="apiConfig" raml="api.raml" doc:name="Router" >
<apikit:flow-mapping resource="/resourceOne" action="get" flow-ref="flow-1"/>
<apikit:flow-mapping resource="/resourceTwo" action="post" flow-ref="flow-1"/>
</apikit:config>
As you can see the calls to these two resources are being redirected to the same flow, but based on the method action.
How do I read this action value (Get or Post) in the called flow flow-1?
I believe you should be having separate flows, but if you need to it this way, you can use #[attributes.method] to get the method of the HTTP Request. The APIKIT router will forward the same event that the HTTP Listener will receive, so it will contain HTTPRequestAttributes. For more info you can refer this section HTTP Request Example
Related
I am new at ExpressJs. so I have some questions about middlewares. So,when do we have to use route middleware in ExpressJs?
First off middleware is code that generally operates on a number of incoming requests. For example, you might have some middleware that checks a cookie to see if this request is authorized before allowing routing to other request handlers to continue. If the request is authorized, it would call next() to continue routing to whatever route handles that specific URL. If the request is not authorized, then it would send an error response and stop further routing. There are thousands of possible uses for middleware - authorization checking is just one such example.
So, you would use middleware when you have multiple routes that all want some sort of pre-check or pre-processing done before the individual routes get called.
Since you asked about "route middleware", perhaps you also wanted to know when you would use middleware on a specific router rather than on the app object. That would be the same when you want middleware to apply only to the routes that are directed to a router object, not on all routes. That can also be done by specifying a path for the middleware such that is only gets called for certain paths.
You can use middlewares when you want to filter your requests before it goes to the next step and make an operation that you want to do there. For e.g in following ways you can have make use of middewares:
Validate
Authorization
Access levels
Restrict requests calls
In the Cumulocity guide, https://www.cumulocity.com/guides/event-language/introduction/, there is a mention of Event Streams for HTTP.
HTTP ResponseReceived SendReqeust This group of events represents sending http requests to external services.
This means we can send outbound HTTP request to external services using the "SendRequest" stream. However, I did not find any further details in any documentation. Can you please provide the template CEL details for SendRequest, and how to configure the same in Cumulocity?
I can not help you using the actual engine (Apama) but I can give you one example using Esper.
#Name("Sending the http request")
#Resilient
insert into
SendRequest
select
'post' as method,
'https://tenant.cumulocity.com/inventory/managedObjects' as url,
'Basic .....' as authorization,
'application/json' as contentType,
toJSON(m) as body
from anyEventStream m;
The toJSON if a function that takes the event stream and return is equivalent in json.
You can find more info here. This info is hide from the actual docs and think it is because they want to push developers to use APAMA instead ESPER.
Hope this helps.
Suppose that I invoke the following HTTP request:
https://accounts.example.com/oauth2/auth?
scope=openid+email&
nonce=53f2495d7b435ac571&
redirect_uri=https%3A%2F%2Foauth2demo.appspot.com%2Foauthcallback&
response_type=id_token+token&
client_id=753560681145-2ik2j3snsvbs80ijdi8.apps.googleusercontent.com
Which yields the following redirect response:
https://oauth2demo.appspot.com/oauthcallback#
access_token=ya29.AHES6ZSzX
token_type=Bearer&
expires_in=3600&
id_token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwiY...
What is the point of the callback parameter, given that the returned metadata, containing id_token, etc., is positioned after a hash fragment in the URI, and are therefore not persisted as parameters to the callback function? How can a server-side callback receive the various tokens?
The response type that is used here is a so-called "Implicit" response type which is primarily meant for in-browser (e.g. Javascript) clients, in which case the Javascript code that is served on the callback URL can access the parameters in the fragment. Web applications should do either one of:
stick to the code flow which is meant for web application clients
use the Form Post response mode (http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) if supported by the OP
serve Javascript on the callback URL that parses out the parameters from the fragment and POSTs them to the server
Bottom line is that if you need the tokens server-side, you should most probably use the code response type.
I am having a very similar issue to this post here: How to use custom route middleware with Sails.js? (ExpressJS)
in that I want all non ajax requests (or all routes with the prefix /api) to load the same view, regardless of route. I have implemented the given answer in that question, but came across the issue that the policy is not called for any unspecified routes.
If I was to catch all routes so that the policy was called, all my blueprints would be overwritten.
Ideally, I would catch all routes last, after the blueprints, since every non API route should be sent to the front end.
I am using angularjs for the front end and want angular to deal with all non API routing.
I would rather not use a .htaccess file as I need to put session information into the page on it's initial load.
Thanks
It seems like your use case is very similar to a HTTP 404 Error situation - you want all requests which don't satisfy blueprint (and possibly route.js) routes to be handled in the same manner.
From api/responses/notFound.js:
* NOTE:
* If a request doesn't match any explicit routes (i.e. `config/routes.js`)
* or route blueprints (i.e. "shadow routes", Sails will call `res.notFound()`
* automatically.
*/
You can have special handling code here which calls the appropriate view if the request path contains /api:
if (req.path.match('^/api')) {
return res.view('your-view-here');
}
I'm new to Apache Camel. Can someone explain what "direct:start" means in Camel.
Please see
https://camel.apache.org/components/latest/http-component.html
from("direct:start")
.to("http://myhost/mypath");
Thanks.
The "direct:start" above is simply saying that the route starts with a Direct Component named "start".
The direct endpoint provides synchronous invocation of a route. If you want to send an Exchange to the direct:start endpoint you would create a ProducerTemplate and use the various send methods.
ProducerTemplate template = context.createProducerTemplate();
template.sendBody("direct:start", "This is a test message");
There is nothing special about the name start. It is simply the name you are going to use when referring to the endpoint and could have just as easily been direct:foo.
Assume like the direct route as a method with name start , so we need to call the start method /direct route to perform certain operation. The below example will help .
The first route will be triggered when an input file is available in XXXX location and when it reaches line , the actual flow will go to second route. Basically the direct route with from endpoint will be triggered by some producer endpoint.
<route id="fileRoute">
<from uri="file:XXXX">
..
<to uri="direct:start">
</route>
<route id="directStartRoute">
<from uri="direct:start">
<to uri="http://myhost/mypath">
</route>
Apache Camel direct is basically for sending Exchange from one route to another in SAME Camel context. So let’s say you are getting message from AMQ and you want to populate headers for every message you get and then send it to mail recipient list. So here you need to create new router which has following description
from(“direct:populateHeaders”)
.setHeader(“myHeader”, “myHeaderValue”)
.end()
And from any route you can send your Exchange object to this route by writing
...
.to(“direct:populateHeaders”)
...
Its important to keep in mind that this will not work out of your Camel Context.
direct:start provides synchronous ways to communicate between 2 endpoints and this is only been used if you want to communicate using camel messages and not generic file or xml messages.
Consider it like this :
There are two things whenever you are sending a message to camel route.
1. The URI scheme, which defines how your message is going to be delivered. And to which component type it is going to be delivered.
2. URI path, which defines the instance of that component.
Now, to your direct:start location.
'direct' tells that this message should send synchronously to the Direct Component.
'start' tells which instance of the Direct Component this message should be delivered.
Importance of different URI path:
Now consider if you are having to different routes. And wants to produce message from two different threads synchronously. Using 'direct:start' as start point for the routes will not work. Unless you are having some conditional processing component, forget this if you are beginner.
For, successfully deliver the messages to both the routes , you will have to add 2 entries i.e. 'direct:somename1' and 'direct:somename2'. 'start' is not a mandatory thing , you can give whatever name you like to.
I recommend you to read some chapters from Martin Fowler's EIP books. It is a wonderful resource to begin with. This will make you very easy to understand Camel.
It should be fairly easy to explain: exchange is always sent from a source to a destination. For that to happen, you need to create those 02 endpoints: one will consume (yes the start) and the other one will emit.
from("direct:start") means "directly consume the exchange from the "start" endpoint and process it anyhow.
to("direct:start") means "send" the exchange to the "start" endpoint "directly" within the same camel context.
What makes this really ambiguous is that the endpoint itself (i.e: "direct:start") is implicitly created on the fly so when writing your code, you are assuming that there is an endpoint called "direct:start" so you can retrieve exchange from it but you can also send an exchange to it.
Good luck!
forget about start. start is just a name of a halt point (direct).
Direct component can be take as a bridge between routes in same context.