Introducing Transaction Restrictions based on Tracking Properties

Introducing Transaction Restrictions based on Tracking Properties

Ranjith

Author

Category: Atomic Scope

Posted: November 4, 2022

Introduction

  • Atomic Scope is a functional end-to-end business activity tracking and monitoring product for Hybrid integration scenarios involving Microsoft BizTalk Server and Azure Logic Apps. With Atomic Scope, you can get full visibility of your end-to-end business activities.
  • Business Transactions tracked in Atomic Scope will be displayed in the Tracking overview along with track properties based on the roles that the current user has in the levels of workspace and business process alone.
  • In this blog, we will see how users can be restricted from business transactions based on tracking properties.

Key Takeaways

  • Why do we introduce transaction-level restrictions?
  • How to configure the User Access Policy (UAP) profile?
  • Use Cases
  • Advantages and Limitations of having transaction restrictions

Why do We Introduce Transaction Level Restrictions? 

  • As of now in Atomic Scope roles for users can be set for workspace and business process levels. Using this the users can be restricted from business transactions.
  • Workspace roles configuration Business Process roles configuration
  • Based on the roles that the user has he/she will be allowed to access business transactions and perform actions in tracking overview. For example, a user with only the Business Process Reader role will not have privileges to reprocess transactions or assign transactions for reprocessing to other users. Tracking Overview Actions
  • Challenges in existing roles configuration
    • Permissions for users can only be set in the levels of workspace and business process. As there are no roles that can be set for transaction level, if the user has a role for a business process all transactions related to the business process will be displayed in the tracking overview screen.
    • Business transactions cannot be restricted based on the properties tracked from the message content.
  • How having a UAP profile overcomes the challenges.
    • To address the challenges in the existing configuration model, we have introduced a new feature called Manage User Profiles in the setting module. Using this feature transaction-level rules based on the configured properties (Global and Stage properties) for a particular transaction can be configured. The transactions that satisfy the rules will only be displayed on the tracking page.

Configuring User Access Policy (UAP) Profile

Before getting into configuring the UAP profile, let us see how to configure properties for a transaction as the UAP profile is based on the configured properties.

  • In the Business Process configuration screen, after selecting a stage using add property both global and stage properties can be configured along with the data type of the property.
  • Property Configuration

User Access Policy Profile will be displayed in the same hierarchy followed in Atomic Scope, where based on the roles that the user has all Workspaces and Business Processes along with Business Transactions will be displayed for configuring restrictions at the transaction level. Let’s dive into configuring a UAP profile, we can get started by adding a new UAP profile in Manage User Profile under User Management in Setting Module.

Configuring User Profile

As you can see from the above GIF, we can easily add Rules/Conditions for a particular transaction and save them for mapping to a user.

Rule

  • The rule is a virtual container for conditions. A rule can have multiple conditions which can be grouped using logical operators (And & Or). The conditions will be checked in sequential order. The result of a rule is the overall result of the conditions.
  • For evaluating a transaction, the value from option Rule Matching either All or Any is used based on the selection made.
    • All – all rules in the transaction must be satisfied.

Any – at least one rule in the transaction must be satisfied. 

Condition

  • A condition will be having property name, comparison type, value to be compared, and logical operator for grouping if there is any condition added after it. Conditions can be added and removed easily using the add & remove icons next to the respective condition.
  • If a property name is similar, it will be confusing to understand to which stage it corresponds. So, to avoid confusion Stage properties of a transaction will be displayed along with the stage name in brackets.
  • The comparison type of a condition is displayed based on the property data type selected.
    • Ex: Consider a rule containing three conditions, the condition with the property of data type string will be having comparison types (Contains & Not Contains), the condition with property data type number will be having arithmetic comparison types (Greater, Lesser) whereas the condition with DateTime type will be having DateTime comparison types (Before, After).
  • If a transaction does not have any properties configured, adding rules is not possible as there are no properties. Navigating to the respective transaction to configure properties will be difficult if there are many business processes and business transactions, we can easily navigate to the respective transaction in a new tab by using the click here option inside the transaction restriction.
  • After configuring the properties, the refresh option can be used to have all the newly configured properties for adding rules/conditions.

User-Friendly Options

  • If a transaction does not have any properties configured, adding rules is not possible as there are no properties. Navigating to the respective transaction to configure properties will be difficult if there are many business processes and business transactions, we can easily navigate to the respective transaction in a new tab by using the click here option inside the transaction restriction.
  • After configuring the properties, the refresh option can be used to have all the newly configured properties for adding rules/conditions.
  • User-Friendly Options

Orphaned Conditions

  • If any configured property is deleted or edited and is used in any condition, those conditions will be considered orphaned conditions and will not be taken into consideration based on the rule matching selected.
  • Orphaned conditions will be highlighted for easy identification and take necessary actions.
  • Orphaned Conditions

Map UAP profiles to Atomic Scope Users

  • Users can be easily mapped with UAP profiles using the options in Manage Users. Also, UAP profiles can be removed for a user at any point of time in the future.
  • Mapping UAP profile

Note: The user should have at least one role in terms of workspace and business process to map a UAP profile. Users can be mapped with any global UAP profiles that are saved before or a custom selection can be made for an individual user.

Use Case

  • As restrictions are based on the properties that are tracked from message content, business transactions will be restricted if the rules are met as per configuration. For example, consider a user who should only have access to transactions that are from partner-A in that case a simple condition can be configured in the transaction like Partner Name equals to partner-A. So that all transactions from partner-B will not be visible to the respective user and all tracked data related to partner-B will not be accessible to the user.

Advantages & Limitations

  • Advantages
    • Having transaction-level restrictions will help prevent users from accessing business transactions that are not relevant.
    • Restrictions are created based on the tracked properties.
    • Prevent tracked data exploitation.
  • Limitations
    • Either Global or Stage properties should be configured for transactions, as rules and conditions are dependent on tracking properties.
    • If more rules and conditions are configured for a single transaction, then it may affect the performance of the search in the tracking overview.

Search Performance

As previously mentioned, having a greater number of rules and conditions for a single transaction may show a delay in the time taken for search in the tracking overview. Find out the performance metrics for a User without a UAP profile and for a User having a UAP profile with five rules and five conditions in each rule.

Number of Results

Time Taken for User without UAP profile

Time Taken for User with UAP profile

1000

0.738s

0.809s

5000

13.12s

13.49s

10000

56.60s

58.33s

Note: The metrics may vary based on the filters applied and the query searched in the tracking overview screen.

Conclusion

In this blog, we have seen how to configure UAP profiles, map UAP profiles to Atomic Scope users, and the advantages of having transaction level restrictions based on tracking data. Also, we have a lot of other new features & improvements joining the V8.3 club. To explore the full potential of the features in Atomic Scope, You can request a demo or sign up for a free trial.