DPOD Integration with API-C can be applied to only a single API Connect Domains per DataPower Device for Firmware lower than 7.6
...
Limitation on the number of domains that DPOD can monitor on a single IDG
When you define no custom log targets on the IDG, the IDG supports a maximum of 125 domains that DPOD can monitor when the IDG defines no custom log targets.
Before firmware 7.5.2.4 , the IDG supported 500 log targets. Because the default domain requires 3 log targets and each application domain requires 2 log targets, The IDG without custom log targets supports a maximum of 248 domains.
After firmware 7.5.2.4 this number were doubled.
When you enable DPOD monitoring, one new log target is added to the default domain and 2 new log targets to each application domain.
Before you can enable DPOD monitoring:
- View the list of defined domain, to ensure that no more than 125 domains are already defined.
- Run the show log-targets command in Diagnostics mode to determine the number of log targets that are defined.
Known workarounds:
Unless the following calculation results in a positive integer, do not enable DPOD monitoring until you move domains to another IDG.
Max Log targets per device - ((domains x 2) - 1) - number_log_targets
B2B support is limited
At present, the most important B2B features (e.g transaction aggregation) are supported. Configuration sampling and specific filtering in dashboards are part of the current version.
Known workarounds:
Upgrade to v1.0.3 - Configuration sampling is implemented.
Callable rule invocation appears as a separate transaction
At present, monitored devices do not report the front end response payload size nor do they report on the back-end request and response.
Known workarounds:
Upgrade to v1.0.4.0 - a fix was provided.
Error is not displayed in "Extended transactions"
The 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 extended transaction log record will not be generated for the error, and it will not be displayed on the "Extended Transactions" screen.
The 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 extended transaction log record will not be generated for the error, and it will not be displayed on the "Extended Transactions" screen.
However, as previous services do have an error rule, the "Extended Transactions" display will resemble the following:
Known workarounds:
None.
The Extended Transaction facility does not support API-Connect
You must NOT run it in API-C / API-M DomainsNote: In some cases, the Extended Transaction is not deployed on MPG services. This is due to the diversity of configuration in these services.
Customers are encouraged to open a PMR and provide the service configuration - so these cases can be addressed and resolved.
Known workarounds:
None.
Compatibility with APIC 2018
The Application Domain, on which the IDG service is configured must begin with the prefix "APIMgmt".