Tuesday, May 22, 2018

How to avoid getting empty response to client due to slowness in key validation call - WSO2 API Manager

Users may get empty response due to slowness in key validation call due to the possibility of timeout gateway to key manager service call. These timeouts can happen in many different ways like below.
01. Connection timeout happen during establishment phase.
We can address this using axis2 client configuration change. Default connection timeout is 60 seconds and we can change that using below property.
Connection Timeout - the time to establish a connection with the remote host
"CONNECTION_TIMEOUT"
>30000
02. Socket timeout due to inactivity to wait packets to arrive.
We can configure this value as well through axis2 client configuration change. Default value of this property is 60 seconds and we can change that as required.
Socket Timeout - this is the time of inactivity to wait for packets to arrive
"SO_TIMEOUT"
>30000
03. Delay due to slow healthy connection .
In this case connection establishment and packet sending happens as usual. But data transfer between server and client getting delayed. In this case what happens is http client keep sending data to server till it accepts them.  We can recreate this by adding slow proxy or something like that. Here important thing is if we notice this type of delay then all UI operations including logging, token retrieval, update etc will also effect. We do not have specific property to override this waiting time from http client level. After 2 minutes this throws error. But before that after 1 minute source handler getting timeout and user will get empty response as it breaks connection.
To send some sort of error to client source handler should wait more than 2 minutes without getting timeout. So if we increase passthrough level socket timeout to 3 mins or so then it will wait till key manager error comes due to data send error. Then key validation handler will send proper unclassified authentication error with error code. Increasing passthrough socket timeout will effect all APIs deployed in the system as its transport level property. But most of the cases proper clients will have timeout values in client level so they will not effect due to this changes. If some client waits forever without having timeout then they will get error like below.
{"fault":{"code":900900,"message":"Unclassified Authentication Failure","description":"Error while accessing backend services for API key validation"}}
To set socket timeout please edit following property in passthru-http.properties.
http.socket.timeout=180000
Please refer this[1] document to understand more about client properties.
[1]http://hc.apache.org/httpclient-3.x/preference-api.html#HTTP_connection_parameters

Monday, January 1, 2018

How to manage external/internal gateways and store with single publisher - WSO2 API Manager

We usually use external API stores only for advertising purposes. If they need to consume API then they have to come back to original store and subscribe there. But as we see your requirement is slightly different from that.

Let me explain you how most of our users handle API usability for internal/external users. I'm sure these external and internal users are resides in different user groups. If that is the case, then we will be able to map them to different user roles. And then we can set the visibility to only required group. For an example if we have API which expose sensitive information then we can set visibility of that API to internal_role role. Then users with internal_role role can only see that API, External users will not be able to see that API or subscribe that.

If we think of deployment then, API Store node will be deployed inside corporate network and outside network pointing to same database. Based on logged in user we can show them right APIs. This solution proposed to you assuming same data shared between both external and internal deployments.

Let me give you exact steps we need to follow,
01. Create 2 different roles for internal and external users(named internal and external).
02. Deploy API Manager internal and external gateways and configure publisher to publish them selectively.
03. Store also can deploy internally and externally pointing to same databases.
04. To create internal only API, create API with limited viability to internal role. Then publish this API to internal gateway.
When internal user logged into internal API store they will see API and can consume it(as they have internal role).
When external user logged into external API store they will not see above API and cannot use that. If they try to access API from external gateway then it will also failed as API not deployed there.
05. To create internal/external API, create API with limited viability to both internal and external role. Then publish this API to both internal and external gateways.
When external user logged into external API store they will see API and can consume it(as they have external role).
When internal user logged into internal API store they will see above API and can use that. If they try to access API from external gateway then it will also work as API deployed there.
06. To create external only API, create API with limited viability to external role. Then publish this API to external gateway.
When external user logged into external API store they will see API and can consume it(as they have external role).
When internal user logged into internal API store they will not see above API and cannot use that. If they try to access API from internal gateway then it will also failed as API not deployed there.