Is possible to get the users IP that triggered the API call on WSO2 API Manager and pass it on to the call?
Any help how to do this please
You can add following property before calling endpoint (before send mediator) to your api to get the ip of user
<property name="client_ip_address"
expression="get-property('axis2','REMOTE_ADDR')"
scope="transport"
type="STRING"/>
Since the scope is set to transport the client_ip_address is set as a header of outgoing message. You will be able to see something similar to below log when the wire is enabled.
[2016-01-21 15:44:10,187] DEBUG - wire << "client_ip_address: 172.22.99.122[\r][\n]"
Hope this will help you.
Related
I create simple api with URI-template
/my_context/{param1}?b={param2}
I created simple sequence for sending email message to endpoint with address
mailto:user#gmail.com
I opened link
/api/my_context/123?b=222
And found in log messages:
Send TO: user#gmail.com/my_context/123?b=222
Incorrect Address.
Why WSO2 ESB append uri to email address?
Removing REST_URL_POSTFIX property like this will change that behavior.
<property name="REST_URL_POSTFIX" action="remove" scope="axis2"/>
We have our API being managed by WS02 API manager, but there seems to be some issue with the way it constructs the outgoing request into the configured endpoint URL. We see this sort of error from our endpoint when we make a request to the API manager:
Cannot bind to address "http://<HOST>:<PORT>http://<HOST>:<PORT>/<RESOURCE>
The URL is clearly incorrect as it is prepending the host part of the URL twice. We've put a debugging proxy in between the API manager and our endpoint and it shows the outgoing request looks like this:
GET http://<HOST>:<PORT>/<RESOURCE> HTTP/1.1
...
Host: <HOST>:<PORT>
It isn't normal for the host to be included in the first line; that should come from the "Host" header. But as it is, it makes sense we are getting the above error. Note, when we proxy this through something like Nginx, it works fine, but the server we are actually using for our endpoint doesn't like it. I'm guessing Nginx has been written in such a way so that it can resolve this kind of (technically incorrect) request.
We are adding propery 'POST_TO_URI' to our synapse API configuration in order to make the outgoing URL a complete URL [1]. This is useful when sending the messages through a proxy server. You can remove that property by modifying your API in AM_HOME/repository/deployment/server/synapse-configs/default/api/ directory. Remove the below property in your relevant APIs which sending requests to such backend servers.
<property name="POST_TO_URI" value="true" scope="axis2"/>
[1]https://docs.wso2.org/display/ESB460/HTTP+Transport+Properties
We have just installed our WSO2 ESB, and we are trying to create some proxies services with customs endpoints.
The default endoint format is:
http://{host}:{port}/services/{Proxy Service Name}
I'd like to have something like:
http://{host}:{port}/services/utilities/{Proxy Service Name}
http://{host}:{port}/services/public/{Proxy Service Name}
I followed this tutorial:
http://wso2.org/library/knowledge-base/2011/01/custom-urls-wso2-esb-proxy-services
but we have a problem, when I send a request to my custom endpoint, I have no answer.
suggestions?
I assume that you were able to properly create a custom endpoint and "I have no answer" means you didn't get any response. If it is the case following are the possible reasons for that,
Proxy service endpoint didn't receive the request
Proxy service didn't configured properly to response back
So test whether the 1 is the reason you can simply put a log mediator with following configuration in inSequence,
<log level="full"/>
then if the proxy service received a message it will log it in console. If that works could you please post your proxy service configuration to check whether it is properly defined.
Well, it seems that we've found a solution, I'm going to resume the full solution.
As the tutorial indicates, to costumize your proxy service endpoint, you have to add the following handler on the axis2.xml configuration:
<handler name="CustomURIBasedDispatcher" class="org.apache.synapse.core.axis2.CustomURIBasedDispatcher"/>
Then, you can customize your endpoint on the design view or on the source view, I've choosen the source view, adding this parameter:
<parameter name="ServiceURI">/services/intern</parameter>
The custom endpoint is autogenerated as:
http://{host}:{port}/services/intern.myWebservice
But I has not worked for me. If I send a request to the custom endpoint, I have no response.
I've solved the problem, adding to the "ServiceURI" parameter the name of the service:
<parameter name="ServiceURI">/services/intern/myWebService</parameter>
then you have to send the request to the following endpoint:
http://{host}:{port}/services/intern/myWebService
So now you have a custom endpoint for every proxy service.
Thanks Malith for your help.
As near as I can tell, the WSO2 ESB does not properly handle proxying a service operation that does not return a response message.
Here's the scenario:
We've got a code-first, axis2 generated web service sitting on WSO2 application server 4.1.0.
The java class that the service is based on has some methods like:
public void updateMyObject(MyObject obj) throws MyServiceException
Axis2 generates a WSDL that does not contain a response message, so this is essentially one-way.
NB: An axis2 generated client stub operating against this operation works fine. When invoking the stub in client code, the client blocks until the operation is successfully processed by the server. If an error occurs on the server, then the custom fault is raised and an exception is thrown on the client side.
But, we want to make this invocation via the ESB. Setting up a simple, basic proxy server will not work. When invoking the service via the ESB, the client code blocks indefinitely even though the remote service was successfully invoked.
I read somewhere that this can be fixed by adding the following to my inSequence:
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
This does the trick in the case that the remote service successfully processes the response. The client code no longer blocks.
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error.
This is no doubt because there is no call-back handler registered for the operation because of the OUT_ONLY setting. Search for OUT_ONLY in the link below for more info:
http://techfeast-hiranya.blogspot.ca/2009/12/wso2-esb-tips-tricks-03-transport.html
The FORCE_SC_ACCEPTED setting seems to be the thing that will keep the client from blocking on the success condition, presumably because that forces a 202 http response to the client so it stops waiting for a response.
Since the client operates as it should against the service for both success and error conditions but I am unable to configure a proxy service that yields the same behavior, in my opinion, the ESB is deficient in this way and that is a bug.
Of course, if there is a way I can configure it so that it does what I want, then I'd love to hear it.
But as near as I can tell, I think not registering a call-back is the wrong thing to do here, even if there is no response. I do not wish to implement a fire and forget here. Executions should still happen synchronously from the client side. My client is expecting an HTTP 200 response but with no body for success.
By examining the WSDL, the ESB should realize that the service has no response message but still register a call back. When the 200 OK is received on success, it should propagate this back to the client and unregister the call-back. When a Fault occurs, it should also relay that back to the client.
So, is there a way to accomplish what I want with the ESB or is it deficient in this way?
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error
What is happening to your client if you define a fault sequence for your proxy in this case?
If we register a call-back fro an outonly operation, what will happen is ESB will wait forever for the response and will run out of threads..
In oneway message;
If it is a successcase use these two properties;
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
For a failure case handle that in the fault sequence. I would like to know, what is happens in the fault scenario.
I am trying to programmatically retrieve the meta data of the end points configured to WSO2 ESB (Eg: ServiceName, WebMethods, Input/Output Parameters with Return types etc). Can someone direct me to some way/docs which could help me fetch this data.
Unfortunately it's not really clear what you want to do. Here some examples how to access properties (Meta-Data?)
inside a proxy/sequence access properties:
<property name="some name" expression="get-property('registry','conf:resource/path')"/>
<property name="some name" expression="get-property('registry',gov:resource/path')"/>
<property name="some name" expression="get-property('registry','resourceName')"/>
Or inside a Custom Mediator:
String property = (String)messageContext.getProperty("nameOfThePropery");
Or inside a Custom Mediator (getting the filename from the Transport Layer):
org.apache.axis2.context.MessageContext axis2messageContext = ((Axis2MessageContext) messageContext).getAxis2MessageContext();
// print the filename of the current transport
myLog.info("FileName: " + axis2messageContext.getTransportIn().getName());
Hope this helps you a little bit further, otherwise improve you question.
To further improve on Abdul's question, we are developing a web-service gateway between a legacy client on side and on the other side are external web-services. We have created a template/sequences in WSo2 where we trap the legacy client request and redirect it to the correct web-service based on a internal protocol.
The external web services are registered in WSo2 as endpoints. So far we have been configuring these endpoints manually using the admin console. We are looking at automating this step so that our gateway will hit WSo2 and provide the WSDL URL. A class mediator would then invoke the WSo2 / Synapse APIs to save this endpoint in the Synapse configuration. We have not been successful in this.
We have also read the docs which say that changing synapse config thru mediator is not recommended, hence would like to see if there are other options that would do this job for us.
One workaround would be to create those endpoints from the client side itself. This can be done by calling the AdminService APIs exposed by the carbon framework. In carbon, a front end of any carbon component talks to its back end through Admin Services. For example, if we take endpoints related functionalities, when you use the management console to create/delete or to do any functionalities, it would in turn call the respective back end via the "EndPointAdmin" admin service. Therefore I believe, if you want to programmatically create those endpoints, you can call the EndPointAdmin backend admin service (via EndPointAdminStub - it is the client stub corresponding to the aforesaid back end service) directly from your client side and get your requirement fulfilled.
Regards,
Prabath