Frequently asked questions

Why is there a mismatch between the count of transfers per account / per emitter type / at a global level?

You may experience such an issue when neutral transfers are reported by SecureTransport. As a side effect, dashboards presenting metrics per Internal/Partner emitter type will not take those transfers into account.

When a transfer is marked as neutral, it means that the account or the transfer site relating to this account has not been previously configured as internal or partner

Perform the required configuration following the Mandatory SecureTransport configuration rules

What is the difference between a temporary and a permanent failure?

Temporary failure – This status indicates that a transfer has failed and that the server will attempt the transfer at least one more time. The default number of re-attempts is five by default, so the actions configured for a temporary failure will be executed after the 1st, 2nd, 3rd, and 4th transfer failures.
This status also applies for client-initiated transfers. It handles the cases where the CIT has failed for some reason (lost connection, user aborted the transfer, etc).

Permanent failure – This status indicates that the transfer has failed and that the server will not retry the transfer. Usually this means that the last retry attempt has also failed.

Why are there errors when trying to resubmit a transfer?

When an error occurs at transfer resubmission,  an error message will be displayed in the tooltip beside the resubmit button.

The reason can be one of the following:

  • The resubmit route is not started or the SecureTransport server has not been configured yet. For more information, see Configure the SecureTransport server.
  • The reason is internal to SecureTransport, then the json error message returned by the instance is displayed in the tooltip beside the Resubmit button

Why are there errors at startup of the absorption route?

This issue is mostly encountered when the application start date property is not properly set in the Axway Decision Insight configuration, as stated in the deployment guide.  Make sure that this date corresponds to the application import date, and that the UTC offset is specified from the time zone that is used by the Decision Insight instance. 

To make sure that you are using the proper time zone:

  1. On the main menu, click Configuration, then on the left menu, click Rhythms
  2. Click on any of the rhythms listed, then you will get the time zone in the Details panel.


Why are there transfers sitting in a temporary state for a too long period

The file transfer duration usually depends on its size. Though, when a transfer stays live for a relatively too long period, this is very likely a fake inflight that needs investigation and correction to mitigate any side effect on both performance and accuracy.You can refer to Handling fake stuck inflights for further reading.

Related Links