Versions Compared

Key

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

DPOD Integration with API-C can be applied to only a single API Connect Domains per DataPower Device for Firmware 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

The product DPOD requires some configuration changes to configuration on a at both device and domain levels - such syslog target and more.As for . Theses changes include but are not limited to syslog targets.

At the service level only -  only the optional feature of Extended Transaction requires instrumentation .

To see the full list of changes please look at this table

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 release since v105 few operation maintenance service to assist day to day operational task such backups, configuration sync.

As this features has system wide influence and might affect the availability of the your Gateway and services we provided limitations on the usage of the features.

For backups - see limitations here.

For Configuration sync - see limitations here.


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 DataPower has language different than English

Choosing language in DataPower 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).

No Support for Tenant feature

Lately in Firmware 7.6 the tenant module was introduced only to physical appliance type 8436. Currently DPOD is not supporting this feature.

Known workarounds:

None. Resolution of this issue is part of the short term product Roadmap.

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:  NEW! - DPOD  DPOD version 1.0.2 and IDG Firmware 7.5.2 with iFix ... .1 (especially  with iFix IT17479: JSON PAYLOAD NOT CAPTURED BY WSM AGENT )  should provide this functionality out of the box!The customer can manually modify the services to include a formatter, or use DPOD's custom logging mechanism to add payload data to the transaction details

Transactions under the Default domain are not monitored

This limitation is derived from a limitation of the monitored device. Log  

Log targets defined at the Default domain collect all logs from all domains, and currently there is no available filter on way to apply a filter to the log targets in order to filter out logs from other applicative 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

to be monitored

that DPOD can monitor on a single

gateway

From 7.5.X it might support up to 500 - http://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/logtarget_logs.html (Perior IDG currently has a limit of 256 Syslog log targets per instance.)

By default each domain will have 2 syslog target defined by IDG.

Since DPOD currently adds another 2 log targets for each monitored domain, and 1 for default domain,

Customer will also have its own log target to other system (like Security tools)

So Number of domain is Equals to :    {500 -[Number of Existing Domains * 2]  - [Customer predefined syslog targets] }/ 2

DPOD can monitor up to 125 domains, if no other Syslog log targets are defined on that device.

Known workarounds: Customer encouraged to move some of its domains to another device.

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:

  1. View the list of defined domain, to ensure that no more than 125 domains are already defined.
  2. 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,

B2B has

the most important

features supported such transaction (IDG term) aggregation . Still

B2B features (e.g transaction aggregation) are supported. Configuration sampling and specific filtering in

dashbaoards

dashboards are part of the current version.

Known workarounds:

None. Resolve this issue is part of the product roadmapCallacble

Upgrade to v1.0.3 - Configuration sampling is implemented.

Callable rule invocation appears as a

seperated

separate transaction

At present, monitored devices do not report the front end response payload size

. Nor

nor do they report on the

backend

back-end request and response.

Known workarounds:

 None. Resolve this issue is part of product roadmap

 

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 being raised but by the service (WS-Proxy) the following situation are possible depends on the applicable scenario:

No error rule in the service

that

where the error is

being

raised

on and previous

. Previous services are configured with "Process HTTP errors = on"

Since

As there is no error rule, an extended transaction log record

is

will not

being

be generated

and there

for the error

is

, and it will not be displayed

in "extend transactions

on the "Extended Transactions" screen.
The extended transaction display will

look similar to

resemble the following (

you can see that

note: one record is missing)

:

Image Modified

No error rule in the service

that

where the error is

being

raised

on but previous

. Previous services do have error rule configured

Since

As there is no error rule, an extended transaction log record

is

will not

being

be generated

and there

for the error

is

, and it will not be displayed

in "extend transactions

on the "Extended Transactions" screen.

Previous

However, as previous services do have an error rule

so the  "extend transactions" screen will look similar to

, the "Extended Transactions" display will resemble the following: 

Image Modified

Known workarounds

None.

The Extended

transaction is not supporting APIC / APIM.

Transaction facility does not support API-Connect

You must NOT run it in API-C / API-M Domains

Note: In some cases, the Extended

transaction

Transaction is not deployed on MPG services

because of

. This is due to the diversity of configuration in

this

these services.

Customer encorage

 

Customers are encouraged to open a PMR and provide the service configuration - so

this

these cases can be

aligned.

No support for DHCP 

No support for DHCP network condiguration. Please reffer to Change Appliance Network Address

addressed and resolved.

Known workarounds:

 None

 

None.