{"id":70365,"date":"2017-11-09T16:00:51","date_gmt":"2017-11-09T14:00:51","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=70365"},"modified":"2017-11-09T12:21:46","modified_gmt":"2017-11-09T10:21:46","slug":"openhub-framework-next-interesting-features","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2017\/11\/openhub-framework-next-interesting-features.html","title":{"rendered":"OpenHub Framework – Next Interesting Features"},"content":{"rendered":"

This is the third article from the series about OpenHub framework<\/a> – the first\u00a0introduced OpenHub framework<\/a>\u00a0and the second presented\u00a0asynchronous messaging model<\/a>.<\/p>\n

This last article from the series will introduce some other interesting features in more detail and it will show the reasons why OpenHub can be a good choice for your integration project.<\/p>\n

Throttling<\/h2>\n

Throttling is a functionality that checks the count of input requests to integration platform and if this count exceeds the defined limit then new requests are restricted.<\/p>\n

The main goal of throttling is to limit\u00a0disproportionate (and often wilful) overload of integration platform with huge amount of input requests for processing. This would have bad impact on the application performance and it can even stop the processing of current messages.<\/p>\n

Throttling component<\/a> counts input requests from specified source (external) system and for specific operation. If this count exceeds the defined limit in the defined time interval then OpenHub will start to reject new input requests (only requests from specified source system and for specified operation) – exception is thrown.\u00a0Throttling component supports cluster.<\/p>\n

Throttling functionality can be configured as follows:<\/p>\n

###############################################################################\r\n#  Throttling configuration\r\n#\r\n#   There the following property names:\r\n#   - throttling.defaultInterval: default time interval (in seconds) if not defined by system\/operation\r\n#   - throttling.defaultLimit: default limit if not defined by system\/operation\r\n#   - throttling.sourceSystem.operationName, where\r\n#       - sourceSystem is specific source system or '*' if any system\r\n#            (source system is case-insensitive value from trace header (ExternalSystemExtEnum))\r\n#       - operationName is specific operation name or '*' if any operation\r\n#\r\n#   Property values (except for default values) have the following format:\r\n#       limit [\/interval]\r\n#\r\n#   Examples:\r\n#       throttling.crm.op1=10\r\n#       throttling.crm.*=10\/40\r\n#       throttling.*.sendSms=60\/30\r\n###############################################################################\r\n  \r\nthrottling.defaultInterval=60\r\nthrottling.defaultLimit=60\r\nthrottling.sourceSystem.*=300\/60\r\nthrottling.*.syncHello=15\/60\r\nthrottling.*.asyncHello=50\/60\r\n<\/pre>\n
For example:
 
<\/div> <\/div><\/p>\n
throttling.crm.op1=10<\/em>\u00a0\u00a0(restriction to calls of operation op1<\/em> from CRM<\/em> system to 10 requests for 60 seconds)
\nthrottling.crm.*=10\/40<\/em>\u00a0(restriction to calls of any operation\u00a0from\u00a0CRM<\/em>\u00a0system to 10 requests for 40 seconds)
\nthrottling.*.sendSms=60\/30<\/em>\u00a0(restriction to calls of operation sendSms<\/em>\u00a0from\u00a0any\u00a0system to 60 requests for 30 seconds)<\/p>\n
Alerts<\/h2>\n
Alerts<\/a> define metrics for watching database data and if any metric exceeds its limit then alert is activated and further operation can be executed.<\/p>\n
Metrics are configurable – the SQL query for getting count of items and limit for checking.<\/p>\n
Examples of alerts (also with follow-up operations):<\/p>\n