ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
latest (15.4.0) 15.3.0 15.2.0 15.1.0 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x 13.5.0 13.4.x 13.3.x 13.2.x
User Community Service Desk Downloads
If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

ONE Troubleshooting Guide

The following guide is intended to provide support in response to the most common causes of errors you might face while working with ONE.

If you do not find a solution to your issue, contact the Ataccama Support team.

This guide is intended for advanced users, that is, those with access to Ataccama ONE Desktop and the application configuration in the ONE web application (Organization tab).

Profiling

Job stays in Submitted status after a long period of inactivity

Problem

After ONE has been idle for a long time, for example, over 12h, the first subsequent job does not progress past the Submitted state. Any following jobs are performed without issues.

Possible cause

There is an issue with how the logging context is cleared after a subscription attempt fails.

Possible solution

There are two options depending on whether you need to use auditing in Data Processing Module (DPM) or not:

  1. Auditing can be disabled.

    If auditing is already enabled in DPM, you can turn it off by setting the property ataccama.audit.enabled=false in DPM configuration.

    For more information, see DPM Configuration, section Audit configuration.

  2. Auditing cannot be disabled.

    If you need to continue using auditing, set the property ataccama.authentication.internal.jwt.generator.streamingTokenExpiration in DPM configuration to a value that exceeds the expected idle period, for example, 18h.

    The property accepts the following units: ns (nanoseconds), us (microseconds), ms (milliseconds), s (seconds), m (minutes), h (hours), d (days).
    Keep in mind that extending the validity of the JWT token can potentially lead to security issues as the subscription can remain active even after the token has been revoked.

User synchronization

Imported user information is not correctly synchronized

Problem

Users that have been imported from Keycloak are not correctly updated in ONE. The same issue can occur in earlier releases, but as it causes the application to fail, the same solution cannot be applied.

By default, users are synchronized by their Keycloak identifier. If you are migrating users from one Keycloak instance to another, the identifiers are generated again.

This is why it is necessary to define how users are merged before they are imported. The following options are available:

  • PERSON_UNIQUE_USERNAME: Users are merged if their usernames match.

  • PERSON_UNIQUE_EMAIL: Users are merged if their emails match.

  • PERSON_UNIQUE_USER_ID: Users are merged if their Keycloak identifiers match.

For more information about how to configure this option, see MMM Configuration, section User provider plugin configuration.
Possible cause

To determine what caused the synchronization issue, start by checking the Metadata Management Module (MMM) logs. To do so, follow these steps:

  1. Open the MMM log file (spring-boot-logger.json.log). By default, in self-managed, on premise deployments, the log file is located in the directory specified through the property logging.file.path. Typically, the property points to the log folder within the MMM installation folder (/opt/ataccama/one/mmm-backend/log).

    Keep in mind that the log output (file or console), format (plaintext or JSON), and location might differ from the ones provided here depending on your logging configuration. See Logging Configuration.

  2. In the log file, look for the messages with one of the following action identifiers:

    • actionId=user-synchronization status=FAILURE

    • actionId=user-synchronization-scheduled status=FAILURE

  3. Check whether the following details are present in the exception:

    • Exception type: com.ataccama.one.metadata.md.intfc.transaction.ValidationsResultException.

    • Constraint type: UNIQUE.

  4. If the exception information matches, in the web application (Organization > Persons) search for the persons whose identifier is provided in IdsInViolation in the log.

    The application should contain only some of these entities as those that break the constraint are rollbacked. These rollbacked entities can be found in the MMM log.

    The constraint type indicates the issue that prevented user synchronization: * constraintId=PERSON_UNIQUE_USERNAME: The newly imported users contain usernames that are in conflict with the person whose identifiers are provided in IdsInViolation. * constraintId=PERSON_UNIQUE_EMAIL: The newly imported users contain emails that are in conflict with the person whose identifiers are provided in IdsInViolation. * constraintId=PERSON_UNIQUE_USER_ID: The newly imported users contain user identifiers that are in conflict with the person whose identifiers are provided in IdsInViolation.

Possible solution

The issue can be resolved in one of the following ways. As all of them have some drawbacks, the most suitable solution depends on your needs and particular use case.

  • Select a different unique key for synchronization. This is done through the property plugin.user-provider.ataccama.one.synchronization-unique-key. If the appropriate unique key is chosen, users are correctly paired and the synchronization issue is avoided.

    In self-managed deployments, the property plugin.user-provider.ataccama.one.synchronization-unique-key is configured either in the mmm-be deployment in the Configuration Service or in the application.properties file located in /opt/ataccama/one/mmm-backend/etc folder.

    For more information, see MMM Configuration, section User provider plugin configuration.

  • Delete the user whose information is causing the issue. If you have changed the synchronization unique key and the issue is still present, deleting the affected user should be a safe option. However, if a matching user is reimported later, it is not linked to the deleted user.

  • Change the value for which a conflict is reported so that it is unique. However, this might not be a viable option for practical reasons.

Lookups

Uploading a lookup file fails

Problem

When trying to manually upload a lookup file (Lookup Items tab), it fails with the following error: Upload of <user_file>.lkp failed.

Possible cause

To determine what caused the upload issue, open the log file and look for the error message. If the error is Refused to connect to <URL>, the property that allows the connection from ONE to ONE Object Storage (MinIO) is likely misconfigured or missing.

Possible solution

Make sure the MinIO URL is correctly configured in the property ataccama.one.webserver.content-security.extra-urls.

/opt/ataccama/one/one-webapp/application.properties
ataccama.one.webserver.content-security.extra-urls={'img-src':{'<link_to_minio>'}, 'connect-src':{'<link_to_minio>'}}.

Depending on how your configuration is managed, the property ataccama.one.webserver.content-security.extra-urls is configured either in the mmm-fe deployment in the Configuration Service or in the application.properties file located in /opt/ataccama/one/one-webapp/etc/ folder.

For more information, see ONE Web Application Configuration.

SMTP

Problem

When trying to send mail, it fails with the following error: SMTPSendFailedException: 530 Authentication required.

Solution

Confirm you have passed the parameters -Dmail.smtp.auth=true, -Dmail.smtp.starttls.enable=true, and -Dmail.smtp.ssl.protocols=TLSv1.2 to the relevant JVM.

The Sendmail step can be run on a DQIT server, a ONE Runtime server, or as a DPE job. If running as a DPE job, the parameters must be set in plugin.executor-launch-model.ataccama.one.launch-type-properties.LOCAL.env.JAVA_OPTS.

For more information, see Executor configuration in DPE Configuration.

Connectivity issues

Problem

When trying to connect to your data source, it fails with either an unknown host or timeout error. The cause might be in ONE, or on the infrastructure or network level. For example, DNS, VPN, firewall, or IP address allowlisting.

Possible solution

Use command line tools to determine if ONE is the cause of the problem. Depending on your platform, you can use either curl, telnet, openssl, or nc, for example:

  • curl -v telnet://<hostname>:<port>

  • curl -v www.googleapis.com

  • telnet <hostname> <port>

  • openssl s_client -connect <hostname>:<port>

  • nc <hostname> <port>

The curl command also displays some useful SSL handshake information, including the Subject and Issuer fields of the server SSL certificate.

Was this page useful?