I am trying to consume a restful Web service using camel.
For that I am configuring dynamic endpoint url as the RESTful url is created at the runtime. Everytime I am checking if the particular endpoint url is registered as a route in my camel context using following method of CamelContext class.
Endpoint hasEndpoint(String uri);
In this case, if the endpoint is not registered then I add a route to my camel context using a custom Route Builder.
I am using camel HTTP component for this. This is working fine for me as of now.
However, I believe performance wise this is not good as everytime I have to check if a route is registered with the camel context and if not then register the same before making the webservice call.
Can some body please tell me if there is a better way to consume RESTful Web services in camel?
I also want to know if the RESTful webservice I am consuming uses OAuth 2.0 protocol, do I need to change anything in my code as I am just consuming it?
Regards, Nilotpal
Thanks for your reply.
I am checking if the route is already exists to make sure I don't end up adding duplicate route(s) to the camel context.
Regarding long lived routes and route dynamics, can u please explain a bit regarding this? How do I implement route dynamics?
It would also be helpful if you could point me to some CXF-RS producer example.. I read the documentation of CXFRS but could not understand it clearly.
Thanks
Nilotpal
Exactly why do you need to check if the route is registred or not before making the call? You should perhaps setup a more long lived route and route dynamic towards resfull resources.
As for Rest with camel, I think the HTTP component does a great job, but there are higher level components to use as well, more designed for REST.
CXFRS and Restlet, producer examples for restlet can be found in the Apache Camel source unit tests, such as this RestletProducerGetTest.java.
As for oAuth 2.0, Camel has some oAuth support built-in, especially for google. Look for the gauth component. There is even a tutorial, however it might not be aligned with your case, it still might give some background so you could solve your issues: http://camel.apache.org/tutorial-oauth.html
CamelContext context = new DefaultCamelContext();
My Aim
I am trying to intercept the incoming request and based on the ip of the incoming request i want to invoke dynamic endpoint of get offers
context.addRoutes(new RouteBuilder(){
public void configure(){
from("jetty:localhost:9000/offers")
.process(new Processor(){
public void process(Exchange exchange) throws Exception {
//getting the request object
HttpServletRequest req = exchange.getIn().getBody(HttpServletRequest.class);
//Extracting information from the request
String requestIP=req.getRemoteAddr();
/**
* After getting the ip address i do necessay processing
* and then add a property to exchange object.
* Destination ip address is the address to which i want to
* send my request
*/
exchange.setProperty("operatorAddress",destinationIpAddress);
}
})
.to("direct:getOffers")
.end();
}
});
Now i will invoke the getOffers endpoint
so first i will register it
context.addRoutes(new RouteBuilder(){
public void configure(){
from("direct:getOffers")
.toD("jetty:${property.operatorAddress}/api/v2.0/offers?
bridgeEndpoint=true")
.end();
}
});
so we can access the operatorAddress property of exchange object as
${property.operatorAddress}
also when we have dynamic routes then we need to call
.toD() and not .to()
Related
Let's say we have a GraphQL NestJS application which acts as a proxy between a client and a REST API server. It's got 3 layers:
Resolver
Services (which kinda have the business logic and stuff)
Something extending HTTPService with added functionalities
We want to add dynamic headers to NestJS outgoing requests to REST API server, which uses axios. The headers are based on:
User: We can read user with the help of User decorator in resolver and pass it down to services, or read it from the GraphQL context as far as I know.
Routes: Different endpoints may require different headers. I think we can specify the types of header that should be added because of a specific rout in the service, but this does not look so scalable... . Or maybe we can store an object of the current paths, that we make requests to. Intercept outgoing requests and use RegExp to determine which path is the request is being sent to (i.e. user/3 would translate to user/:id, which we can add proper headers knowing that).
[
{
path: 'user/:id',
...
},
{
path: 'user/:id/image',
...
}
]
So my question is how can we add headers to outgoing requests from a NestJS application to some endpoints based on the path(url of the axios request) and the current user. Is matching a url with some RegExps while intercepting an outgoing request expensive?
Had the same problem and solve it by using Injection Scopes in Nest GraphQL
https://docs.nestjs.com/fundamentals/injection-scopes#request-provider
However, there's a caveat in terms of performance.
I want to 301 redirect the URLs from previous site that are nested, as pencilblue doesn’t support them,
e.g. a/b to page/b
For this I have been experimenting in include/http/request_handler.js but facing some issues.
Call never comes inside RequestHandler.prototype.handleRequest or even RequestHandler.prototype.onSessionRetrieved (seems these methods are not being called from anywhere)
Therefore I placed the code in RequestHandler and after confirming that req is not for public resource or api, I create a new url and execute
return this.doRedirect(newUrl, 301)
This actually works but at the same time I receive
Can’t render headers after they are sent error
#1075 has not helped me much as I’m not sure which specific controller I should modify. I need to catch the req as early as possible and see if it’s a page then redirect to page prefixed url.
Thanks in advance.
There are couple of ways to do redirects. You can do them from a controller or from middleware. You are correct in that, some of the functions in the request handler are not called. These are deprecated despite the fact pencilblue team didn't mark them as such. They replaced a good deal of the request handler functionality with /include/http/router.js and include/http/middleware/index.js. Plugins can register their own middleware to hijack the request pipeline.
See Advanced Routing on wiki for more info about creating your own middleware.
Using the routing framework your plugin would be able to register middleware that would be able to inspect the request and then redirect based on your specific criteria. The Router will be accessible from req.router and from there you could call req.router.redirect (Source).
Reference: #1224
I am using a service fabric Rest API and i need to add some custom headers to my requests.
I am using both a stateless implementation of the service fabric.
When receiving information in the HttpMessageRequest I have the headers there containing information.
I initiate my stateless service using the following code:
// in api controller:
proxy = Proxy.ForMicroservice<IServiceInterface>();
// in the Proxy class:
public static I Create<I>(Uri serviceAddress, UserData data) where I : class, IService
{
var returnval = ServiceProxy.Create<I>(serviceAddress,listenerName:Naming.Listener<I>());
return returnval;
}
I tried the following article (from stack overflow) but it seems to be oriented on WCF. I also expected there to be a more out of the box information about this.
How can i maintain my header information which I received in the original call, or at least transfer this information to my stateless service, without using something like an wrapper Data transfer object?
You can use CallContext to set the headers . After wards,follow this sample on how to send customHeaders to service .
https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/tree/master/Services/ServiceRemotingCustomHeaders/ServiceRemotingCustomHeaders
It looks like you want to do something like this Passing user and auditing information in calls to Reliable Services in Service Fabric transport. You need to set and pass your custome header information in the fabric transport call end then pick that up on the recieving (service side). CallContext can be used to convey that header information from the MethodDispather to any internal service logic without having to rely on expanding your service methods to include it as arguments.
I have been using a .net library to create an oauth session, and submit, modify and cancel orders using the ETRADE api. Now I need to listen for account & order events. As per the ETRADE API documentation, they use CometD & long poling. I did find a .net CometD implementation. However, the ETRADE API docs says that one must pass some oauthHeader to initialize the CometD session. Does anyone know exactly what that oauthHeader is? Any sample code would be appreciated.
I modified to the oauth .net library to provide the same oauth header that gets passed to other API http requests:
public string GetOauthAuthorizationHeader(string url)
{
NameValueCollection headers = _session.Request(_accessToken).Post().ForUrl(url).GetRequestDescription().Headers;
return headers[Parameters.OAuth_Authorization_Header];
}
Passing this header to cometd works. I did have to change to a different .net commetd library (nthachus's commetd.net), though; the one I was previously using was ignoring these headers.
I am trying to create a few restful webservices that will add a bit functionality to the company cisco phones. The basic idea is simple, the users get a small client on which they need to enter login and password. When they have done so, their phone/phones are 'registered' to my restful service and they get added functions on their phone. When they log out, they get unregistered. To provide the extra functions (like adjusted caller information etc etc) I need the Cisco AXL API. This is a SOAP based API. I have generated the java classes using the wsdl already. When I make a testclient using the generated classes, all works fine.
But here comes the problem: When I try to run a soap request while my application is deployed on my Tomcat 7 container, it doesn't work anymore.
The problem seems to be the AXLAPIService, which hangs when executing the following piece of code:
#WebEndpoint(name = "AXLPort")
public AXLPort getAXLPort() {
return super.getPort(new QName("http://www.cisco.com/AXLAPIService/", "AXLPort"), AXLPort.class);
}
In other words, i am not getting a port for the soap request and it makes the tomcat crash i f you wait long enough.
I went googling. Somebody on some forum once had a problem because of an out of date stax version. I adjusted the stax version in my POM and tried again, to no help.
I also read somewhere that the underlaying javax.xml.ws.Service actually has an enumeration of ports, and when you do getPort(), you will get the most appropiate port. I then looked up the default port for SOAP and that would be 80, just like the port used for RESTful services. Could it be that the soap service would be wanting port 80, but that it can't have it because it is already in use?
So, to summarize my question:
can it be that my restful services consume the same port that my soap
request would want to use?
if not, what could be the problem then and how should I fix it?
As additional information, this is how the axl wsdl defines the service:
<service name="AXLAPIService">
<port binding="s0:AXLAPIBinding" name="AXLPort">
<soap:address location="https://CCMSERVERNAME:8443/axl/"/>
</port>
I was thinking about changing the soap port myself. Some googling tells me I should do that in the wsdl but I wouldn't really know how. There is post already here but I fail to see how binding another portname could help me out....
As with so many things involving Cisco Telephony and their Administrative XmL (AXL), I found a workaround instead of an actual answer. Since a problem never really leaves my mind, I spent the rest of yesterday trying to find a solution for getting information out of that AXL thing.
Any actual answers to the above questions are still welcome though.
The workaround I found is this: Since SOAP can be seen as a special http POST request, it should be possible to do a SOAP call using a REST framework such as Jersey. You just need some extra code to make it work. I used the 'SoapProvider' from the link and for those who are also wrestling with this, I'll add my code:
public void doSoapRequest() throws SOAPException, JAXBException{
ClientConfig config = new DefaultClientConfig();
config.getClasses().add(SoapProvider.class);
Client c = Client.create(config);
c.addFilter(new LoggingFilter());
c.addFilter(new HTTPBasicAuthFilter("user", "password"));
MessageFactory messageFactory = MessageFactory.newInstance();
SOAPMessage message = messageFactory.createMessage();
SOAPPart soapPart = message.getSOAPPart();
SOAPEnvelope envelope = soapPart.getEnvelope();
SOAPBody body = envelope.getBody();
SOAPElement bodyElement = body.addChildElement(envelope.createName("getCCMVersion", "", "http://www.cisco.com/AXL/API/8.5"));
message.saveChanges();
WebResource service = c.resource("https://youraxlmachine:8443/axl/");
// POST the request
ClientResponse cr = service.type(MediaType.TEXT_XML).header("SOAPAction", "\"https://youraxlmachine:8443/axl/getCCMVersion\"").post(ClientResponse.class, message);
message = cr.getEntity(SOAPMessage.class);
JAXBContext ctx = JAXBContext.newInstance(GetCCMVersionRes.class);
Unmarshaller um = ctx.createUnmarshaller();
GetCCMVersionRes response = (um.unmarshal(message.getSOAPPart().getEnvelope().getBody().extractContentAsDocument(), GetCCMVersionRes.class)).getValue();
System.out.println("HERE COMES THE VERSION!");
System.out.println(response.getReturn().getComponentVersion().getVersion());
}
I have left as many things unchanged as I could, except for the company specific details. This code works for getting the CCM version.
WARNING: Depending on how you perform the request, you might get a different result for the same request. I'll explain:
I have implemented other AXL methods as well, such as getUser. Before I even coding the Jersey soap service, I tried everything with SOAPUI. So I setup the SOAPUI so I could do RESTful requests to the AXL server. Using my restful setup in SOAPUI, I get the same results as I when would do the standard SOAP calls using both SOAPUI and my first implementation of a soapclient in java.
But when I use the jersey client to do the same getUser request, some important fields are missing from the result. I have no clue what could have caused this. For the request getPhone, I dont even get a valid response. So be warned.