DPOD integration with API-C can be applied only to a single API Connect domain per Gateway device for firmware level lower than 7.6
This limitation is derived from a limitation of the monitored device.
Known workarounds:
Upgrade to firmware 7.6 or 7.5.2.8.
Changes to gateway objects
DPOD requires some configuration changes to both device and domain levels. Theses changes include, but are not limited to, creating Syslog log targets.
At the service level - only the optional feature of Deprecated Extended Transaction requires instrumentation.
To see the full list of changes please see Gateway changes performed by DPOD.
No support for DHCP
DPOD does not support DHCP network configuration. Please refer to Change Appliance Network Address.
Known workarounds:
None.
Operational maintenance plan limitations
DPOD v1.0.5.0 and above offers several operational maintenance features that assist in scheduling and performing day to day tasks such as backups, configuration syncs and firmware upgrades.
These features have system wide influence and might affect the availability of monitored devices and services. Please consult the following limitations:
Operating System supported locale
The only supported operating system locale definition for DPOD is en_US.UTF-8 as described in the installation prerequisites.
Object names in non-English languages may be partially supported.
Known workarounds:
None.
Limited functionality is provided when Gateway has language different than English
Choosing a language in Gateway will impact your Syslog records . This will cause DPOD to provide limited analysis on records that are not in English.
Known workarounds:
Change language of your monitored device to English (en).
WS-M does not capture Multi Protocol Gateway services payloads for firmware pre 7.5.2
This limitation is derived from a limitation of the monitored device.
Known workarounds:
DPOD version 1.0.2 and IDG Firmware 7.5.2.1 (especially with iFix IT17479: JSON PAYLOAD NOT CAPTURED BY WSM AGENT) should provide this functionality out of the box.
Transactions under the default domain are not monitored
This limitation is derived from a limitation of the monitored device.
Log targets defined at the default domain collect all logs from all domains, and currently there is no way to apply a filter to the log targets in order to filter out logs from other application domains.
Known workarounds:
There is a workaround, but it only applies if the customer is willing to duplicate all network traffic, or alternatively run transactions only on the default domain. Please contact support for more details.
Payload size does not include response size (only request size)
At present, monitored devices do not report the front end response payload size, nor do they report on the backend request and response.
Known workarounds:
None. Resolution of this issue is part of the product Roadmap.
Limitation on the number of domains that DPOD can monitor on a single IDG
When you enable DPOD monitoring, one new log target is created in the default domain and two new log targets in each application domain.
IDG supports a maximum of 500 log targets prior to firmware level 7.5.2.4, and a maximum of 1000 log targets on firmware level 7.5.2.4 and above.
Since IDG already contains two built in log targets in each application domain, DPOD can monitor up to 124 application domains prior to firmware level 7.5.2.4 and up to 248 application domains on firmware level 7.5.2.4 and above.
Before you enable DPOD monitoring:
- View the list of defined domains, and ensure it does not exceede the number domains described above.
- Run the show log-targets command in Diagnostics mode to determine the number of log targets that are defined.
Known workarounds:
Montior only part of the domains, or move domains to another IDG device.
B2B support is limited
At present, only most important B2B features (e.g transaction aggregation) are supported.
Known workarounds:
None
Error is not displayed in "Deprecated Extended Transaction"
The Deprecated Extended Transaction is the only feature of DPOD that involves instrumentation of an XSLT transformation to the Web Service Proxy policy (request / response and error rules).
The instrumentation is integrated by the system only when initiated by the system administrator and not by default.
The behaviour when an error is raised by the service (WS-Proxy) depends on the applicable scenario:
No error rule in the service where the error is raised. Previous services are configured with "Process HTTP errors = on"
As there is no error rule, an Deprecated Extended Transaction log record will not be generated for the error, and it will not be displayed on the "Deprecated Extended Transaction" screen.
The Deprecated Extended Transaction display will resemble the following (note: one record is missing)
No error rule in the service where the error is raised. Previous services do have error rule configured
As there is no error rule, an Deprecated Extended Transaction log record will not be generated for the error, and it will not be displayed on the "Deprecated Extended Transaction" screen.
However, as previous services do have an error rule, the "Deprecated Extended Transaction" display will resemble the following:
Known workarounds:
None.
The "Deprecated Extended Transaction" does not support API-Connect
Known workarounds:
None.