Fabric Web Services are REST APIs that, among other purposes, allow external access to Logical Unit's data. The Fabric Web Services are exposed through the Fabric Web Service layer. Fabric receives multiple requests concurrently, thus the Web Service response time is highly important.
Fabric Smart Proxy mechanism allows to redirect the Web Service calls between multiple nodes based on the configuration of the web server filters. The logic behind establishing what node should be invoked is based on a built-in hash function, which is applied on the values of the Web Service input argument as well as the parameters of the web server filters.
One of the most common reasons for using this mechanism is the need to optimize the LUI retrieval process, in order to reduce the Web Service response time. When LUI data is retrieved by the Web Service, Fabric uses the cache mechanism to load an instance into the memory. As the Fabric MDB cache files are stored on a server, it is more difficult to utilize the cache in a multi-node environment. This is due to the fact that each Web Service call might be redirected to a different node and consequently the cache will be stored on different servers. As a result, when the same Web Service is invoked again for the same instance ID, the cache is most likely not going to be reused. The Smart Proxy mechanism can solve this issue by redirecting the call to the same node when the same input is received and thus reduce the Web Service response time.
The Smart Proxy mechanism is off by default. It can be applied by setting the web server filters via the config.ini file as explained further in this article.
Note that the Smart Proxy mechanism is applicable for GET requests only.
The Web Server filters in the config.ini are empty. To set up the filter, uncomment the default setting:
#WEBSERVER_FILTERS=
and populate it as follows:
WEBSERVER_FILTERS=[{"class":"com.k2view.cdbms.ws.ProxyAPI", "params":{"fabric_redirect":"SERVER", "fabric_retry":"1", "fabric_tokens":"token1, token2", "fabric_affinity":"", "read_timeout_sec":"60", "connect_timeout_sec":"60"}}]
The web server filter parameters are defined as follows:
All the parameters can keep their default values except for the fabric_tokens parameter, whose value - token1, token2 - must be replaced with the name(s) of the input argument(s) used by the Web Services.
For example, when a Web Service has an input parameter called ID, the filter should be set to:
WEBSERVER_FILTERS=[{"class":"com.k2view.cdbms.ws.ProxyAPI", "params":{"fabric_redirect":"SERVER", "fabric_retry":"1", "fabric_tokens":"ID", "fabric_affinity":"", "read_timeout_sec":"60", "connect_timeout_sec":"60"}}]
When a Web Service has several input arguments, all of them need to be listed as the fabric_tokens value.
Fabric Web Services are REST APIs that, among other purposes, allow external access to Logical Unit's data. The Fabric Web Services are exposed through the Fabric Web Service layer. Fabric receives multiple requests concurrently, thus the Web Service response time is highly important.
Fabric Smart Proxy mechanism allows to redirect the Web Service calls between multiple nodes based on the configuration of the web server filters. The logic behind establishing what node should be invoked is based on a built-in hash function, which is applied on the values of the Web Service input argument as well as the parameters of the web server filters.
One of the most common reasons for using this mechanism is the need to optimize the LUI retrieval process, in order to reduce the Web Service response time. When LUI data is retrieved by the Web Service, Fabric uses the cache mechanism to load an instance into the memory. As the Fabric MDB cache files are stored on a server, it is more difficult to utilize the cache in a multi-node environment. This is due to the fact that each Web Service call might be redirected to a different node and consequently the cache will be stored on different servers. As a result, when the same Web Service is invoked again for the same instance ID, the cache is most likely not going to be reused. The Smart Proxy mechanism can solve this issue by redirecting the call to the same node when the same input is received and thus reduce the Web Service response time.
The Smart Proxy mechanism is off by default. It can be applied by setting the web server filters via the config.ini file as explained further in this article.
Note that the Smart Proxy mechanism is applicable for GET requests only.
The Web Server filters in the config.ini are empty. To set up the filter, uncomment the default setting:
#WEBSERVER_FILTERS=
and populate it as follows:
WEBSERVER_FILTERS=[{"class":"com.k2view.cdbms.ws.ProxyAPI", "params":{"fabric_redirect":"SERVER", "fabric_retry":"1", "fabric_tokens":"token1, token2", "fabric_affinity":"", "read_timeout_sec":"60", "connect_timeout_sec":"60"}}]
The web server filter parameters are defined as follows:
All the parameters can keep their default values except for the fabric_tokens parameter, whose value - token1, token2 - must be replaced with the name(s) of the input argument(s) used by the Web Services.
For example, when a Web Service has an input parameter called ID, the filter should be set to:
WEBSERVER_FILTERS=[{"class":"com.k2view.cdbms.ws.ProxyAPI", "params":{"fabric_redirect":"SERVER", "fabric_retry":"1", "fabric_tokens":"ID", "fabric_affinity":"", "read_timeout_sec":"60", "connect_timeout_sec":"60"}}]
When a Web Service has several input arguments, all of them need to be listed as the fabric_tokens value.