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
...
at both device and domain levels.
...
These changes
...
At the service level - only the optional feature of Deprecated Extended Transaction requires instrumentation.
...
are details in Gateway Changes Performed by DPOD.
No support for DHCP
DPOD does not support DHCP network configuration.
...
Known workarounds: Please refer to Change Appliance Network Address.
Known workarounds:
None.
...
Maintenance plan limitations
DPOD
...
includes several operations maintenance plans to assist in the day to day operational tasks, such as backups, configuration
...
sync, firmware upgrade, etc.
...
As these features have system wide influence and might affect the availability
...
of the Gateway and services
...
, they include limitations on the usage of the features.
For backups - see limitations here.
For configuration sync - see limitations here.
For firmware upgrades - see limitations here.
For appliance migration - see limitations here.
DPOD 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:
...
.
Limited functionality is provided
...
when DataPower has a language different than English
Choosing a language in
...
DataPower will impact
...
the content of the Syslog records sent to DPOD. This will cause DPOD to provide a limited analysis on records that are not in English.
Known workarounds:
...
Change the 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:
...
Partial support for tenant feature
In DataPower firmware 7.6, the tenant module was introduced only to physical appliance type 8436.
Only capturing transactions on tenant devices is supported.
The following features are currently not supported for Tenant devices:
Device resource monitoring
Appliance Maintenance (Backup, Sync, Firmware Upgrade)
Extended Transaction
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
...
way to apply a filter to the log targets in order to filter out logs from other application domains.
Known workarounds:
...
See Monitoring Transactions in the Default Domain 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:
...
DPOD integration with API-C can be applied to only a single API Connect domain per DataPower Gateway for firmware lower than 7.6
This limitation is derived from a limitation of the monitored device.
Known workarounds: Upgrade to firmware 7.6 / 7.5.2.8 or later.
WS-M does not capture multi-protocol Gateway services payloads for firmware lower than 7.5.2
This limitation is derived from a limitation of the monitored device.
Known workarounds: Upgrade to firmware 7.5.2.1 or later.
Limitation on the number of domains that DPOD can monitor on a single
...
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.
...
gateway
...
Since the DataPower gateway currently supports up to 1,000 log targets, DPOD can monitor a maximum of 333 domains per each gateway, if no other custom log targets are defined. See details and calculation below for more information.
This limitation is per each DataPower gateway and has no effect on the number of gateways that can be connected to DPOD.The total amount of log targets per each DataPower gateway cannot exceed 1,000 and consists of:
One required default log target per domain (created when the domain is created with the name
default-log), which cannot be removed.Additional custom log targets, created by the customer for non-DPOD use.
Log targets created by DPOD - DPOD will create one log target for the default domain, and 2 log targets for each monitored application domain.
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:
Count how many domains should be monitored by DPOD (except the default domain) -
DOMAINS_COUNTCount how many log targets already exist in the DataPower gateway -
EXISTING_LOG_TARGETS_COUNT
You can view the existing log targets in the DataPower gateway WebGUI under default domain → Log Target Status → Show All DomainsMake sure the following calculation is true:
Code Block EXISTING_LOG_TARGETS_COUNT + (DOMAINS_COUNT x 2) + 1 < 1,000
Known workarounds: If the number of expected log targets exceeds the limit, do not enable DPOD monitoring. You may use the following methods to allow for DPOD monitoring:
Reduce the amount of monitored domains by setting up monitoring only for selected domains (see Configuring Monitored Gateways).
Delete unused domains or move domains to another gateway.
Delete unused custom log targets that were created for non-DPOD use.
B2B support is limited
At present,
...
the 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:
...
Configuration sampling and specific filtering in dashboards are part of the current version.