OpsHub Integration Manager provides you with both templates and the ability to define custom mapping between your ALM systems to support mapping of both data fields and linkages. Select a template for standard out-of-the-box integration between the two selected ALM systems. Once the mapping has been selected or custom-defined, you can use the built in Mapping Validator to make sure that your mapping is setup properly before going to production. OpsHub Integration Manager supports maintaining various types of relationships (parent-child, traceability, etc.) between the entities being synchronized.

OpsHub Integration Manager has deployment options to fit the needs of your business: - On-Premise: OIM can be installed as an on-premise solution to become a fully integrated component in your infrastructure. - Customer Cloud: OIM can be installed in customer's cloud environment, including Windows Azure or Amazon EC2. - Hosted: OpsHub can host OIM on behalf of the customer to offer OIM as a SaaS

OIM ensures that a complete history is maintained of your ALM activities as the entities flow between your integrated ALM systems, ensuring that you always have a complete picture and are compliant with applicable regulations. History is maintained even when one of your individual systems becomes unavailable and once the system is again operational, all transactions that occurred during that time will be reflected in operating system.

Robust conflict detection and resolution capabilities are built into the OpsHub Integration Manager platform. If a conflict resolution mechanism is configured, then the conflicting transaction states are passed into the configured conflict resolution. If the conflicts are not resolved (either because there is no conflict resolution mechanism present or the configured conflict resolution doesn’t resolve the conflict) then conflicts are logged into event error queue and can then be manually resolved and the event replayed.

In the event that an entity fails to be synchronized for some reason, such as target ALM systems is unavailable, OIM will proactively notify the administrator of the failure. Via the web based administrator tool, the administrator can identify the failed transaction, view the reasons for the failure, and either resolve the condition, such as restarting the unavailable AM system and retry or use the built-in editor to modify the transaction to resolve the failure condition. OpsHub also has built in support for automatic recovery management. Bugs, process failures, system failures can happen while updates are in-flight or in the process of being applied to the destination system. OpsHub provides guaranteed automatic recovery from the failures once the system becomes operational. It will automatically recover from the failures and make sure all changes are processed even if the failure happened during the processing of a transaction. No transaction/changes are ever lost or duplicated.

OpsHub Integration Manager support the application of changes to target system in transactions blocks from the source system. This ensures that proper workflow transitions are executed when the changes are applied to the destination systems. No transitions are missed, ensuring that all the notifications associated with various transitions are also executed.

OpsHub supports a number of replication models to support your development organization: - Master/Slave: The entity is mastered at one system and read only copies are created in other ALM systems. - Partitioned Ownership: Different fields of the entity are mastered at different systems. - Dynamic Ownership: Entity ownership changes dynamically, but at any one time there is only one master based on the value of a field in the entity. - Peer-to-Peer: Multiple sites can make changes to entities and it typically requires conflict detection and conflict resolution. - Custom: The replication model is custom defined and typically some mix of the previous models.

Various business rules can be specified and configured for the validating the proper preconditions for checking in changes into source control systems. The rules are not dependent on the use of any frontend IDE/tool. They work across all check-in’s and are always enforced. The rules can access information from other systems to evaluate the rule. Rules can be used to enforce check-in policies, like the corresponding issue/ticket must be in assigned state, or reviewer must be specified as a part of check-in.