Micro Focus Connect planning guidelines

This topic provides guidelines on how to plan a deployment of Micro Focus Connect in your organization.

Roles and responsibilities

Micro Focus Connect requires network proxy and certificate configuration, and the provisioning of access credentials. These items need to be updated regularly, as certificates and credentials typically have expiration dates.

For proper operation in an enterprise environment, Micro Focus Connect requires the usage of back-office utilities such as Windows/Linux shell scripts and the scheduling of regular automated maintenance tasks, in the format of Windows Scheduled Tasks or Linux cron jobs.

Some of these automated tasks are critical for the stable operation of Micro Focus Connect, such a s a regular database purge. Others enable special synchronization scenarios that are otherwise not feasible, or which require customer-specific scripting.

Due to the above, smooth operation of Micro Focus Connect requires the following skills typical for administering common backend systems:

Server OS skills, for example shell scripting, CPU, monitoring and management for memory and disk space, and backup and restore processes.
Networking skills, for example, proxies, certificates, and firewalls.
Knowledge of the operational parameters, deployed configurations, and add-ons of the endpoint products to be synchronized via Micro Focus Connect.

Considerations for use cases

This section describes the synchronization use cases and what you need to consider when planning a use case.

After you understand your needs, you fill in a worksheet in which you specify you specific endpoints and fields. For details, see the Planning Guide and Worksheet.

Types to synchronize

When planning a Micro Focus Connect configuration, you need to first determine your use case. You should have answers to these questions:

Question	Description
What type of users are working in each product?	Who are the users? Are they developers, testers, product owners, or user with another role?
What are the roles of those users?	Are they responsible for the creation or update of the entities, such as the backlog items, issues, requirements, and bugs?
What are the roles of the products?	What system is used to record and store entities, for example stories, sprints, defects, and tests?
What type of information needs to be shared between the users of both products?	Determine what information needs to be shared. Micro Focus Connect is not intended to be a full replication tool. Its intended use is to synchronize the most relevant information to the parties involved. This means that not all types and fields will need to be synchronized. We recommend starting with a basic use case and expand it as needed.
Which users will create which items?	Determine which users will be creating items. For example, if using ALM/QC with Azure DevOps, one scenario would be for a user of Azure DevOps to create backlog items that are sent to ALM/QC as different requirement types. Then, users of ALM/QC can update the fields on those backlog items/requirements in Azure DevOps. ALM/QC users may create defects that are synced to Azure DevOps for resolution by the development team.
Which subsets of data need to be synchronized?	Generally, there is a subset of types that need to be shared between roles or products. Maybe you are synchronizing backlog items to requirements and defects to bugs, but tasks may not be relevant to the other team.
What are the permissions?	Will the users of the other product be allowed to update the field information and synchronize it back?
Are there relationships or links between types?	These relationships may be required or optional. For example: In ALM Octane, sprints can only exist within a release and cannot be moved between releases. Therefore, you cannot create a sprint in ALM Octane unless you have created or designated a release for it to exist within. This is a data model type of relationship. Relationship fields. This can apply to a planned sprint field in a user story. Although the sprint field may look like a regular field, in most products, it is a relationship or link field. Therefore you need to indicate to Micro Focus Connect the sprint item type to set the sprint field on a story. There are many features in Micro Focus Connect to help you configure this. For details, see Relationship mapping.
What is the direction for the synchronization?	The direction that you set at the type level in your connection dictates which product can create that item type. In most cases, the direction should be unidirectional. If you find that your use case calls for bi-directional creation of items for many types, it is often an indication of a process or governance problem that needs to be addressed. However, bi-directional updates of certain fields for example, Status, Author, and Comment - are prevalent use cases.
Do you already have information synchronized between the two products?	A common scenario for organizations new to Micro Focus Connect is the move from another synchronization technology, or the manual entering of artifacts into two products. If this is the case, you can indicate to Micro Focus Connect that these items already exist in both products and should not be newly created. By following these steps, you can avoid duplication of data, allowing Micro Focus Connect to pick up where you left off with the other synchronization tool. For best results, validate the configuration in a test environment. For details, see Relationship mapping. In summary, avoid synchronizing all fields and types. This provides no value and can even have a negative impact and complicate the configuration. Clarity about the synchronization use cases and actual business needs is essential. If the use case is not clearly defined, do not set up a connection.

Fields to synchronize

After you have determined the types that need to be synchronized and understand the relationships between the types, you need to consider which fields need to be synchronized. Setting the direction on the field level indicates which product can update that field on that item. In general, bi-directional field updates are more common than bi-directional type creation.

Choosing the field types

Fields are of different data types and planning a synchronization requires knowledge of the data types. Not all fields are compatible with one another and the data type of some fields is not always easily apparent. For example:

A Date field might internally be of type Date, or of type Date/Time with the time portion not displayed, but also not set to zero. Another example is a String type with a text value resembling that of a date, but the system does not automatically treat it as a date.
Product add-ons may add additional field data types or display fields in a different manner in the product's user interface, compared with how these fields are stored internally. This is especially common with both single-selection and multi-select lists. Micro Focus Connect will always present the field as it is stored internally by the product—not by the modifications made to the UI by the add-on.
Micro Focus Connect may not support all field data types. Refer to the connector's Readme file for a list of non-supported data types.
For some products (for example Atlassian Jira), add-ons might add custom field data types with a custom storage approach. Synchronizing fields of such data types may not be possible and will often require some experimentation. Refer to the connector's Readme file and the Translate Jira epics to features .

Choosing the fields

The choice of which fields to map from one product to the other is driven by your requirements, not the tool. However, the products themselves will not allow you to map incompatible types. If you configure the connection to do so, the products will return an error. For example, if you map a String field to a Relationship field, it will fail.

The following table lists your primary considerations:

Field	Consideration
Read-only fields	Consider a case where the Micro Focus Connect user interface informs you that a field is read-only and that the direction of the synchronization for the mapping will be changed. This information is being reported by the endpoint product itself, not by Micro Focus Connect. Micro Focus Connect is just passing on that product’s response on to your setup. You cannot map a read-only ID to a read-only ID. For example, when synchronizing ALM Octane with ServiceNow, you may want to map the item IDs from both products. Since IDs are system generated fields, Micro Focus Connect cannot override those fields. The same applies to other system generated fields, such as Created time and Modified time. To achieve the use case of seeing the corresponding ID from both products, create a custom field in both products as a text string fields. Then, perform a unidirectional mapping of the ID from each system to the custom ID field on the other side.
Required fields	All required fields on a particular side, master or target, must be mapped when items of that type are being created. Consider the following: Missing field values. Take a case where Severity is a required field in your ALM/QC defects and you are synchronizing defects from ALM/QC to another product. If no defects are being created in ALM/QC by Micro Focus Connect), then Micro Focus Connect will warn you that you are missing required fields for ALM/QC. In that case, you can safely ignore the warning for that type. Default Values. Some required fields have a default value if you do not explicitly set them. For example, the Phase field in ALM Octane is a required field. However, when you create a new item, it automatically sets the phase for you if you do not select one. For those fields, if you are satisfied with the endpoint product setting the default for you, you can also safely ignore the required field warning message. No corresponding field. If you have a required field that must be set, but it does not have a default value, and there is no corresponding field in the originating product, you can use the Calculated Values feature in Micro Focus Connect to set it upon creation. Make sure to determine if the required field is a regular field or a relationship field, as the two require different approaches in their configurations. For details, see Define calculated values.
Enum fields	When mapping enum fields, always map all enums on each side within the value mapping view, even if there are duplicate mappings on one side. Ideally, create matched enum pairs on both sides. If you have duplicate values on one side, the bolded value (the lowest in the list) will be the default value when updating an item TO that product. If that field is a one-way update FROM that product, the bolded value will not be relevant.

Field

Consideration

Read-only fields

Consider a case where the Micro Focus Connect user interface informs you that a field is read-only and that the direction of the synchronization for the mapping will be changed. This information is being reported by the endpoint product itself, not by Micro Focus Connect. Micro Focus Connect is just passing on that product’s response on to your setup.

You cannot map a read-only ID to a read-only ID. For example, when synchronizing ALM Octane with ServiceNow, you may want to map the item IDs from both products. Since IDs are system generated fields, Micro Focus Connect cannot override those fields. The same applies to other system generated fields, such as Created time and Modified time. To achieve the use case of seeing the corresponding ID from both products, create a custom field in both products as a text string fields. Then, perform a unidirectional mapping of the ID from each system to the custom ID field on the other side.

Required fields

All required fields on a particular side, master or target, must be mapped when items of that type are being created. Consider the following:

Missing field values. Take a case where Severity is a required field in your ALM/QC defects and you are synchronizing defects from ALM/QC to another product. If no defects are being created in ALM/QC by Micro Focus Connect), then Micro Focus Connect will warn you that you are missing required fields for ALM/QC. In that case, you can safely ignore the warning for that type.
Default Values. Some required fields have a default value if you do not explicitly set them. For example, the Phase field in ALM Octane is a required field. However, when you create a new item, it automatically sets the phase for you if you do not select one. For those fields, if you are satisfied with the endpoint product setting the default for you, you can also safely ignore the required field warning message.
No corresponding field. If you have a required field that must be set, but it does not have a default value, and there is no corresponding field in the originating product, you can use the Calculated Values feature in Micro Focus Connect to set it upon creation. Make sure to determine if the required field is a regular field or a relationship field, as the two require different approaches in their configurations. For details, see Define calculated values.

Enum fields

When mapping enum fields, always map all enums on each side within the value mapping view, even if there are duplicate mappings on one side. Ideally, create matched enum pairs on both sides. If you have duplicate values on one side, the bolded value (the lowest in the list) will be the default value when updating an item TO that product. If that field is a one-way update FROM that product, the bolded value will not be relevant.

Workflows

Another aspect of the planning process is understanding all workflows and workflow rules in your endpoint products. Micro Focus Connect generally cannot violate any workflow rules that the products have in place. However, there may be exceptions. Some products do not enforce the workflow when the API is being used, which is the way Micro Focus Connect communicates with the products. Some products allow you to have role-based privileges override the workflow restrictions. You can take advantage of this capability using the Micro Focus Connect data source user account/role. In cases where the workflows are respected, you will have to account for this in your connection setup. Take time to determine the products through which Micro Focus Connect will automatically ignore the workflow as much as possible.

Users

User fields in Micro Focus Connect, refer to fields in your connections that have user values. For example, if you are synchronizing a field on defects called Assigned To, it is likely synchronizing a user value. User values are different than other fields as users must exist in the product to set the field to that value. There are several things to consider when planning the synchronization of user fields:

Consideration	Description
User Representation	Different products represent users in different ways. For example, ALM/QC represents users by a username. ALM Octane can represent a user by their full name ‘Gary Bear’, a username ‘GBear’, or by their email address ‘gary.bear@microfocus.com’. Jira represents its users by their full name. Make sure you know how the products you are synchronizing represent users if you intend to synchronize user fields.
User Maps	If you are synchronizing between ALM/QC and Jira and you want to synchronize user fields, you will need a user map in Micro Focus Connect for Gary Bear that shows that he is known as ‘Gary Bear’ in Jira, but as ‘GBear’ in ALM/QC. For details, see Create user maps and apply user matching and MatchByName scripts.
Impersonation	Not all user fields behave the same way in all products. For example, the Assigned to field is usually a field that can be set by a user of the tool whereas Created by or Modified by cannot be set manually. Some products allow impersonation which means that if an item was created in Product A by Gary Bear and synched to Product B, it will set Gary Bear as the creator in Product B, assuming he exists as a user in both products and has proper user maps in place. However, if the product does not allow impersonation, Product B will show the Created by user as the Micro Focus Connect data source account.

Consideration

Description

User Representation

Different products represent users in different ways. For example, ALM/QC represents users by a username. ALM Octane can represent a user by their full name ‘Gary Bear’, a username ‘GBear’, or by their email address ‘gary.bear@microfocus.com’. Jira represents its users by their full name.

Make sure you know how the products you are synchronizing represent users if you intend to synchronize user fields.

User Maps

If you are synchronizing between ALM/QC and Jira and you want to synchronize user fields, you will need a user map in Micro Focus Connect for Gary Bear that shows that he is known as ‘Gary Bear’ in Jira, but as ‘GBear’ in ALM/QC. For details, see Create user maps and apply user matching and MatchByName scripts.

Impersonation

Not all user fields behave the same way in all products. For example, the Assigned to field is usually a field that can be set by a user of the tool whereas Created by or Modified by cannot be set manually.

Some products allow impersonation which means that if an item was created in Product A by Gary Bear and synched to Product B, it will set Gary Bear as the creator in Product B, assuming he exists as a user in both products and has proper user maps in place. However, if the product does not allow impersonation, Product B will show the Created by user as the Micro Focus Connect data source account.

Data model normalization

When synchronizing between products that have different data models, you need to plan for how to normalize those models with Micro Focus Connect.

For example, consider a case where you want to synchronize sprints from Jira to ALM Octane. In Jira, sprints are not required to have start and end dates, and in many cases cannot have start and end dates until they are the active sprint. Additionally, in most versions of Jira, there is no way to relate sprints to versions/releases. In ALM Octane, sprints must be related to a release, they must have start and end dates, the start and end dates must fit within the release with which they are associated, and they cannot move across releases once associated with one. Therefore, if your use case is to define sprints in Jira and send them to ALM Octane, you will need to have a clearly defined approach indicating to Micro Focus Connect which release to associate each Jira sprint with in ALM Octane, to ensure they have correct start and end dates.

Alternatively, since Jira is less restrictive when creating sprints, synchronizing sprints from ALM Octane to Jira would require far less consideration as there are, for example, no default dependencies, date requirements, or release dependencies. These are all considerations when planning your configuration.