Operational Checks

Congratulations : you have configured our Importer Application and set your scheduling. Now you can enjoy the automated synchronization of your data source and your selected version of Importer for JSM Assets.

This page is applicable for all of our Importer Applications listed on the Atlassian Marketplace.

 

What is next?

We recommend periodically checking the following screens starting from left to right and making sure that imports are executed as expected.

 

 

1- Notifications For Your Automation Rule

In case you configured the Notify Me feature, check if you received any notifications via your Automation Rule. Depending on your configuration, the notification can be in the form of a Jira Software Issue, JSM Ticket, Email, Slack Message, Teams Message, SMS, etc. If you have the notification, jump to step 4 below.

2- JSM Assets / Object Types

Open your JSM Site / Assets Menu / Object Schema. Select each object type and make sure you have new objects created or recently updated.

3- JSM Assets / Import History

Check your Assets import history and logs. You will find them by following your JSM Site / Assets Menu / Object Schema / Configuration / Imports tab / View history button. (Related Atlassian Documentation)

  • Make sure that all objects are imported properly at the scheduled or manually triggered time.

  • In case there is a warning message for an object type, then expand the menu and go down to the bottom. There, you will find an error message. Some example errors can be:

Error Examples

Description

How to identify

What to do

Error Examples

Description

How to identify

What to do

Unique violation

This means there were multiple records in the import having the same value for the unique attribute.

The value which was duplicated and the attribute ID is displayed in the error message. Review the Object Type and the Attribute name.

Check your source, and find all the records having the value that you identified in the log. In case there arer multiple values at your source, remove or update the value to fix the data quality issue.

Objects missing a label

Label’s are mandatory fields for every object type. In case there are records without a label, they will be skipped by Assets.

Expand each object type statistics in the import history. Check if the “Objects missing a label“ count. It should be zero. Review the Object Type and the Attribute marked as Label.

If you saw that there are records without a label, check the data source. Make sure that they have the value filled. Once you fix the records, they will be displayed in Assets with the next manually or scheduled executed import.

Attribute validation error

Our marketplace applications use different attribute types while building the object schemas to ensure data quality. I.e. Email, URL, Integer, Double. In case the value coming with the import do not match the attribute type, those records are skipped during the import.

The value which failed the validation is displayed in the error message. Review the Object Type and the Attribute type.

Check the data which caused the error to occur. Check the data source and fix the format of the data at source.

Error Message similat to:

Error: Publisher - Text attribute value must be less than 255 characters long. [Object (Label: AcrobatNotificationClient, Id: Unknown)].

 

This means the value for the Publisher attribute is very long in Microsoft Entra ID (Azure AD) and does not fit in a text type attribute.

 

This may happen if you created your data model before 2024 April.

If the import status is failed , check each object type details and review the error messages.

You may change the type from text to textarea by following these steps:

1- Open the Object view for Applications.

2- Select the list view.

3- Select the “Bulk actions” menu and “Edit objects”

4- Change the value for the “Publisher” attribute to “Remove” and click save.

5- A menu will pop up for you to confirm the deletion of the values of the Publisher attribute. Click “Save” again.

6- Wait for a while to see the “Bulk update complete” notification on the left bottom side of your screen.

7- Select the “Attributes” tab.

8- Go to the row for “Publisher” and click on the cell for “Type Value” column, select “Text Area”

9- Run another import and validate that all objects are created or updated properly.

Error Message similat to:

Error: User(s) (334455667788991122334455) not found in Jira. [Object (Label: Name Surname, Id: 1234)].

 

or

 

Name Surname (Object key: AD-1234): User(s) (334455667788991122334455) not found in Jira;

Maybe because of a release upgrade, Atlassian made some changes and it took time for Assets to recover and fix the index. Asset uses the index to provide answers quickly. Instead of running a DB query every time, it stores the index in memory. However, when the index messes up, the data is not found. In this case the logs were showing the object keys, and saying that they don’t exist. If they don’t exist how did they have a key, right?

If the import status is failed , check each object type details and review the error messages.

Create a ticket to Atlassian on support.atlassian.com and explain the situation.

Your error is not listed above? Send us your error screenshot by creating a ticket, and share your experience, we will be happy to help.

  • In case, you don’t see the import in the history, this means the import was not successfully completed. Then check your Importer Application.

4- Your Importer Application

Open your Importer Application, you will find a note at the top regarding the last execution. A normal message would look as follow.

If you see a message like this one:

Then, you need to configure the application as explained in the message. I.e. adding the correct credentials, adding the correct permissions, etc.

If you don’t see any messages, you can check if there is an ongoing import process in the Admin tab by clicking on “Check Import Status”.

 

A new page will pop up. There, you will find more details on the situation. If you see a cancel button, check the audit logs or debug logs before clicking the cancel button. The cancel button cancels the existing import.

In some cases, JSM Assets may get stuck and not accept new imports. Then, you can cancel the execution and start again.

 

If your scheduled import is not running, then it may be related to the permissions. Please check if you have removed any user from the group starting with jira-servicemanagement-users- and add it back. Also, make sure that this group has a product relation. Here are the steps:

1- Go to admin.atlassian.com

2- Select yoursite.atlassian.net

3- Select the Directory menu on the top

4- Select Groups on the left side

5- Search jira-servicemanagement-users-yoursite group

6- Select Show details

7- Check the Group product access section.

8- Make sure that it has Jira Service Management as the product and User (agent) role

5- Your Importer Application / Audit Logs

Checking the audit logs on the Admin tab will provide information if a configuration has been changed recently.

6- Your Importer Application / Debug Logs

You can also enable Debug logs and run an import to see how the import process is flowing. In case there is an issue with the configurations or the systems, you would be able to observe them in this menu.

If you don’t see a successful import flow in the debug logs, that could mean the import execution duration reached the Forge Limit. Please read the limitations page and learn how to handle the timeouts.

7- Your Data Source

As a last item, you can check your data source. Make sure that:

  • the User/API credentials are working and valid (some systems have expiration dates for the API tokens. I.e. Microsoft Graph used by Azure Ad and Microsoft Intune).

  • You have the correct permissions defined.

  • Your data is accessible.

  • There are no Data Quality issues. I.e. emails are in a proper format, fields are filled as expected, etc.

  • The data source is not having performance issues.

    • I.e. We commonly see different response times for different customer environments in Azure AD. While one import execution can bring a large amount of data successfully in the 25 seconds of Forge time limit, for another customer, Azure AD may be responding very slowly and it may cause the application to timeout even though the number of users and groups are much lower than the other.

      • Important facts:

        • The source system’s performance varies during the day. (They respond slower during the busy hours).

        • If the source system has a distributed architecture, then not every region has the same speed to respond.

  • The data source is in service. Check your data source’s health status.