Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Changes to Gateway objects

...

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.

Limited functionality is provided when DataPower has language different than English

  • Choosing a language in DataPower will impact the content of Syslog records sent to DPOD. This will cause DPOD to provide limited analysis on records that are not in English.
  • Known workaroundsChange language of your monitored device to English (en).

...

  • In DataPower firmware 7.6, the tenant module was introduced only to physical appliance type 8436.
  • Currently DPOD does not support monitoring resources of the tenant feature. Only capturing transactions on tenants is supported.

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 workaroundsThere 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.

Duplicate Syslog messages appear in Raw Messages

  • DPOD uses several Syslog log targets in different domains and configurations.
  • By design, it is collecting some error messages twice, and those messages appear twice in the Raw Messages page or in the Raw Messages tab of a single transaction.
  • This duplication does not break any feature and is required for the correct behavior of DPOD.

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.5.2.1 or later.

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 back-end request and response.

Limitation on the number of domains that DPOD can monitor on a single Gateway

  • When there are no custom log targets defined on the Gateway, the Gateway supports a maximum of 125 domains that DPOD can monitor.
  • Before firmware 7.5.2.4, the Gateway supported 500 log targets. Because the default domain requires 3 log targets and each application domain requires 2 log targets, The Gateway 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 domains, 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 workaroundsUnless the following calculation results in a positive integer, do not enable DPOD monitoring until you move domains to another Gateway:
    Max Log targets per device  - ((domains x 2) - 1) - number_log_targets

...

Error is not displayed in "Deprecated Extended transactions"

  • 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 behavior 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 the Deprecated Extended Transaction feature in API-C / API-M Domains.
  • Note: In some cases, the Deprecated 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 (Ticket) and provide the service configuration - so these cases can be addressed and resolved.
  • Known workaroundsSimilar functionality can be applied with the new non intrusive-extend transaction introduced in v1.0.8.0

...