When you use a product and play around with the features inside it, you might face some challenges sometime. Atomic Scope is a product that can be customized based on the customer’s needs. It is always good to know the basic troubleshooting steps to sort out the challenges. This blog covers the common challenges in Atomic Scope, including the troubleshooting steps.
Common challenges in Atomic Scope:
- Tracking data purging
- Steps need to be taken care of during installation and upgrade
- How to effectively utilize the search mechanism
- How to avoid the challenges while reprocessing a message
Let’s look at them one by one.
Tracking data purging
The purging of tracked data potentially has a significant impact on the product’s performance.
We always concentrate on improving the purging process. However, due to a lack of knowledge about the alternative options available through the portal and difficulty maintaining the infrastructure, users can experience great differences if they don’t know the purging options in the portal.
Without addressing the purging-related challenges, you will be unable to regulate the database growth and SQL timeout errors.
Things to keep in mind include:
- Infrastructure has an important role in the overall performance of the product. The message body size and total number of transactions will differ depending on the stages of the transactions.
- It is vital to grow your infrastructure appropriately based on the number of message transactions and other requirements.
- Purging can take a considerable amount of time, which is due to factors like message size and message volume. This can result in running into time-out exceptions.
- If the message size/volume grows, the user should concentrate on the infrastructure requirements. If a user is experiencing purging issues, always ensure that the infrastructure can handle many message transactions and SQL operations.
- By referring to the screenshot above, the user can view that the last execution time for the purging is clearly shown and that the database size exceeds the 20GB limit, and purging actions have not occurred.
Use case scenario
The default tracking data purge policy is 90 days. However, sometimes a customer environment has data that is older than 90 days in the Atomic Scope Database due to inconsistent purging or purging functionality errors. This huge amount of data in the Atomic Scope table can lead to accumulated issues while purging the older data in the Atomic Scope database.
To solve this kind of issue, we recommend executing the Stored Procedure to purge data older than 90 days manually until there is no more date older than 90 days. After purging, you should restart the Atomic Scope Windows NT service and verify if there are any purging errors in the Diagnostic logs.
Even after purging, if you still get the purging service error in the Atomic Scope diagnostic logs it is suggested to reduce the purging policy to 60 days or up-scale your SQL Server machine to handle huge volumes of SQL operations.
It is also best practice to periodically check if there are any Purging errors in Atomic Scope Diagnostic Logs. Please refer to the documentation.
How to use the purge settings effectively
We have divided the purging process into two phases.
Tracking data purging will occur at 4-minute intervals based on the data count provided by the user (less than 5000). Depending on the message size, we can configure the message count for purging.
Every hour, general purging will occur, with each cycle deleting 10000 records.
The user can also choose the start and end times for purging. The ability to configure off-hours will benefit the customer. As a result, the purging process will not affect the operating hours.
You can check the status of the tracked data purging via the methods below.
- Health check info: The user can determine whether the purge is active or not using the info. So, the user may verify the service and other parameters to ensure that everything is up and functioning. Please refer to the documentation.
- Diagnostics logs: The user can also find the SQL timeout and other exceptions in the logs. It will assist the user in identifying the issue earlier and ensuring that it does not affect their business. Please refer to documentation.
Steps need to be taken care of during installation and upgrade
Let’s look at the common challenges during the installation and upgrade of Atomic Scope.
1. During the installation process, some customers might not install the feature “Atomic Scope – Azure NT services” as they do not use any Azure resources. However, they might not be aware that the same feature is responsible for running the purging activity and alerts in Atomic Scope.
Without the installation of this feature, the purging activity does not happen. Hence, it must be installed for purging activities and Alerts.
2. During the installation/upgrade, you might face an exception in the validation process, as mentioned below:
Exception: Wrong App pool credentials error
In this scenario, it is possible to double-check the IIS App Pool user account by navigating to the path “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Kovai Ltd\AtomicScope\Properties” and checking the IIS_AppPooluser account.
3. While running the samples, the below exception occurs sometimes.
Exception: System.IO.FileNotFoundException: Could not load file or assembly ‘Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ or one of its dependencies. The system cannot find the file specified. File name: ‘Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’
The above exception occurs when the file mentioned in the error is not registered in the Global Assembly Cache (GAC). To fix this issue, navigate to the Atomic Scope installation directory (Kovai Ltd\AtomicScope\Binaries) and GAC the file shown in the error.
4. License deactivation is not required for upgrading.
Unlike the license deactivation process before the upgrade in BizTalk360, the upgrade of Atomic Scope does not require the deactivation of the license.
5. Upgrade Atomic Scope in all relevant servers
This is quite a common scenario when a new version of Atomic Scope is upgraded on the client side. Some customers might miss upgrading to the latest Atomic Scope version on all the machines where they installed Atomic Scope components. This might cause some activities not to get tracked in the portal. Hence, it is mandatory to upgrade Atomic Scope in all the machines where it is installed.
Properties are not getting tracked in Atomic Scope Portal
There are a couple of reasons why the properties not get tracked in the Atomic Scope Portal.
- Pipeline component properties are not configured correctly.
Sometimes, the StartActivity/Update Activity property is set up as “False” at the user end. This would prevent tracking the message events happening through the corresponding pipeline. Hence, it is required to give the StartActivity/Update activity value as “True” as shown below.
Only then the logger component starts tracking the events, and the tracking results will be displayed in the Atomic Scope Tracking Portal.
- Archive Message in the Logger component is disabled.
This is one scenario where the properties of the transactions are tracked correctly. However, the message content and context become unavailable. It is because the ArchiveMessage is not enabled in the Pipeline. It must be set as “True” as shown below, to see the message content and message context in Atomic Scope.
- Deploying a new application
When a new application is deployed in a BizTalk server, sometimes the activity that occurs in the application does not get tracked in Atomic Scope Portal. Hence, every time a new application is deployed in the BizTalk server, it is required to restart the Atomic Scope service, and all the host instances associated with the application.
How to effectively utilize the search mechanism
Atomic Scope’s primary feature is tracking. The user always requires a convenient and precise outcome, but sometimes they struggle with static filters. This might be because it just has a few filters.
- Every time a new property was added to Message Content or Message Context, it was often inconvenient to construct a new property in the Business Process. Only after that has been done, the user may formulate a query and receive results based on the properties.
- The Full-Text search feature can be used to look up business transactions. Due to its dynamic nature, this feature expands upon the regular search capabilities. Suppose any properties exist in the message context and content without having to configure any properties in the business process; the user can then create a search with their desired property name and value. Please refer to the full-text search documentation.
- Create search queries using case-insensitive search keywords, group search keywords with parenthesis brackets, and perform logical operations using logic operators such as AND, and OR.
- To perform wildcard operations, to search for dynamic properties and values, you can use wildcard characters (* and ?) in the search terms.
- The asterisk (*) represents any number of characters, and the question mark (?) represents a single character.
- To get precise search results, users can combine full-text search with other filters such as date and time range, maximum records, and static filters. These filters together serve to narrow the results by the specific criteria.
- Dynamic search can ensure accurate and relevant results while achieving efficient and flexible capabilities.
Key Points
- Determine that messages are archived for dynamic search.
- Logical operators are case-sensitive.
How to avoid the challenges while reprocessing a message
Reprocessing of messages comes into the picture when a message is invalid or has any issues with its content. The frequent challenges concerning reprocessing messages are discussed below:
- Regarding access, if a user who has been assigned the role of Business Process Reader/Message Content Viewer tries to do the reprocessing, it will not work. They need to be assigned to the role of Message Reprocessor. The role can be assigned from the Business Process level in Atomic Scope from the path Business process>Under Actions column>Access Policy>Add Permissions. Note that, the user(s) need to be added under Settings>User management in Atomic Scope so that they are listed under Business Process> Access policy to assign for the role of message reprocessor.
- Sometimes, if a user with Message Reprocessing access tries to reprocess the messages, they may fail. If archiving messages is disabled, then it is not possible to do reprocessing. Therefore, make sure Message archiving is enabled.
- In BizTalk Receive Locations and Send ports, the Archive property of the Atomic Scope pipeline component should be set to “True” as shown below:
- In orchestrations, orchestration activity logger component can be used to archive the messages.
- It is also good to know the number of reprocessed messages and who was assigned to reprocess the messages. This will give clarity and avoid reprocessing the messages that were already processed. The customers can check this information in the portal and the table [dbo].[Config_Reprocess] from the Atomic Scope database.
Conclusion
These are the frequent issues that customers have consistently brought up. Most importantly, if you become familiar with the configurations for setting up purging, you will not encounter any fundamental issues in using Atomic Scope.
