|
|
|
Frequently Asked Questions
General AssistanceQ: I'm confused, which version of the JaM Plugin should I be using? A: While we tried to minimize the confusion, we understand a bit more information could be helpful. All JaM Plugin versions support all versions of QC (through v10). The main difference is with JIRA:
Here's a matrix that should provide additional help:
Q: Help! I've run into a problem and can't seem to find a solution. What should I do? A: If you've reviewed the FAQ below, read through the installation documentation, and have not found a similar issue logged in the JaM Plugin JIRA project, please contact us directly. We do ask that you provide a few pieces of information before contacting us:
If you can provide any logs or other available documentation, that would also be helpful. The quickest way to contact us is to log an issue in the JaM Plugin JIRA project. Our entire support team will see your issue, and other customers can benefit if they are experiencing similar challenges. Q: How does the JaM Plugin interact with JIRA and QC? A: The Go2Group JaM Plugin utilizes a web services based on the SOAP protocol, allowing JIRA and QC to talk. The basic framework looks like: JIRA <> SOAP <> QC Q: Is the Go2Group Mercury SOAP service the same as the Quality Center SOAP service? A: Likely - The product was called TestDirector. HP purchased Mercury, then renamed the product Quality Center. Q: What is Quality Center Kit for JIRA? Is this JaM Plugin? A: This is the actual JaM Plugin - It's what the JaM Plugin was called before it was the JaM Plugin. Q: In the configuration section, two terms "MercuryListenr" and "MercuryService" are mentioned. Should these terms be replaced with other words such as "QCListener" and "QCservices"? A: Yes - Most, if not all, "Mercury" references should be changed to "QC" references in the JaM Plugin. With each release, we attempt to update the product and literature, however some of these references are buried in the code. RequirementsQ: What versions of JIRA and Quality Center work with the JaM Plugin? A: The JaM Plugin works with the following editions/versions:
InstallationQ: Does the JaM Plugin work with HP Quality Center (v9)? A: Yes! The JaM Plugin does work with HP Quality Center v9.2. Q: Does the JaM Plugin work with HP Quality Center v10? A: Yes! The JaM Plugin does work with HP Quality Center v10. Q: Can I use the JaM Plugin in a Linux Environment? A: Yes! Simply install the Mercury SOAP service on a Windows machine and configure the service to point to the Quality Center server. Q: Can I map the following fields in the JaM Plugin configuration?
A: Yes! When mapping the fields, select the multi field type. Then, click the Value Mapping link to set up the specific value mappings. Q: I noticed you have released an updated JaM Plugin - How do I update my installation to the latest version? A: Simple! Just download the latest version (upgrade package) and walk through the upgrade guide. Q: From a technical / communication perspective, how does the JaM Plugin work? A: Basically, you have two servers involved - the Quality Center server and the JIRA server. The communication between the two is entirely over web service (SOAP) calls. The web service runs on the Quality Center server, and the JIRA server talks to it. So, you'd need to have the port that the web service runs on open and available through any firewalls or security. The port can change; the web service runs in an application server, such as Tomcat, which typically runs on port 8080, but you can specify the port you want to use. Q: How do I ensure there is no duplication during the replication between JIRA and Quality Center? A: When performing defect replication, a strategy is required to avoid double replications. That is, unless precautions are taken, an issue replicated from Quality Center to JIRA may trigger a reverse replication from JIRA to Quality Center. The following table lists the precautions taken to avoid this problem in the four replication scenarios.
Q: For which fields in mercury.properties does JIRA needs to be restarted when there is a change? A: You need to restart JIRA for any change in mercury.properties. Q: Does the Mercury Interface webapp need to be restarted when there is a change to mercury.properties? A: You do not need to restart the SOAP web application; it does not use the property file. Q: We have the same users in Quality Center and JIRA, do we need a mapping entry at all? A: No, you only need a mapping entry for fields that must be translated. Q: I am receiving the following message - What could be the cause of the error? java.lang.UnsupportedClassVersionError: Bad version number in .class file A: This indicates that an older version of Java is running. We built JaM using JDK 6 - please use JKD 6 or later if possible. Q: If we have a custom field in JIRA, by which name do we reference it in the mapping file? A: Custom fields should be identified by their field name, e.g. "ReviewedBy". The only restriction is that custom fields should have unique names in JIRA. Q: Where is the plugin actually physically installed? Is it installed on the JIRA server? A: Yes, the JaM Plugin is installed on the JIRA server. Specifically, it is installed in JIRA's WEB-INF/classes folder. Q: Is it possible to manually force updates? A: We do have a feature that allows the user to force updates, but that's really just in case the automatic replication failed for some reason, such as the servers being offline. The normal mode of operation is for automatic replication. Q: Is it possible to have replication in one direction only (QC -> JIRA). A: Yes! The Project Mappings configuration provides directional replication: From JIRA to QC, or from QC to JIRA, or both. Q: Is there support for the QC 'run' object? A: No. We can replicate between JIRA issues and QC defects, and can establish links between JIRA issues and QC test cases. We have no support for the QC 'run' object. Q: What is the "test cases" tab panel in JIRA? A: The 'test cases' tab panel in JIRA shows the details of any QC test cases that were manually linked to the issue. Test case linking is really a completely separate feature from defect replication. Q: I've installed the Go2Group Mercury soap service, but I am receiving a 404 Page Not Found message when trying to access the service by URL. What could be the problem? A: It's possible the port number is being used by an incumbent software. Please uninstall the soap service, then reinstall the soap service using an available port. Q: How do I configure the JAVA_HOME variable? A: A picture is worth a thousand words. Please see PLUGINJAM-375 and reference the first two pictures.
Q: What ports need to be open on the firewall for the JaM Plugin to successfully sync? A: Port 80 for Quality Center, and Port 8080 for the SOAP service. UsageQ: How is JIRA information displayed within a QC Defect? A: You can see from the image below how JIRA information is displayed within a QC Defect. Please note - This will differ depending on you custom fields and mapping strategy. Q: The synchronization of attachments works, but the link that appears in HP QC misses the /jira context. We have defined this context in the mercury.properties as "context=/jira", but it's not inserted into the URL on HP QC side. A: The corresponding JIRA issue must be updated, then the replication will correct the URL for the attachment in QC. Q: Is there a way that linked issues in QC (e.g. duplicates or dependencies) result in linked issues in JIRA? A: We are monitoring the development of JIRA, but this currently is not available through JIRA's Plugin Development Kit - the Issue Link Event is not available. Q: For our workflow to work correctly I need to execute the transitions in JaM (otherwise the incorrect workflow actions are shown in JIRA for an updated status). I now have to define all these transitions in the mercury.properties file, while they're already defined in our JIRA workflow. Why can't JaM get this information from the JIRA workflow? Is this functionality improved in a newer version? A: A feature called autoExecuteTransition is available in versions of the Go2Group JaM Plugin following version 5.0. Q: If a HP QC defect is locked and fields for this bug are updated in JIRA, then the HP QC defect won't be updated (you see an exception in the jam.log). It seems that if you again change a field in JIRA later on when the defect isn't locked in HP QC, that all changed values are synced correctly. Is that correct?
A: Yes, if the Defects in QC are locked, the Go2Group JaM Plugin cannot update the defect from a corresponding change in a JIRA issue. You might avoid this problem by using additional fields for comments in JIRA and QC.
Q: Is there a way to display the synchronization result in a JIRA issue or HP QC defect? We now only see the exceptions in the jam.log and users aren't notified if the synchronization fails due to a lock in HP QC etc. A: In version 5.7 of the Go2Group JaM Plugin, there is a property called logCustomField. Using this property, you can configure a text-type custom field in JIRA, which will then display confirmation and error messages. Q: Can I configure the JaM Plugin to execute workflow transitions to update the statuses between QC and JIRA? A: Yes! We recommend not directly syncing JIRA status and QC status. Rather, in each system, use a custom field to track the status of the other system. SupportQ: Is the Basic (Free) version of the JaM Plugin supported by Go2Group? A: The Basic JaM Plugin is no longer available. Q: Does the JaM Plugin work with other versions of QC? A: The Go2Group JaM plugin was designed and tested with QC 9.0 and above. While we continue supporting the JaM Plugin with newer releases of Quality Center, HP has ended its support with pre-9.x versions of QC. Q: We have a custom field, "The Dukes of Hazzard" - How do we identify this custom field within the configuration file? A: Custom field names with spaces will work just fine. Simply identify the customer field name as: CF_The Dukes of Hazzard Q: Is it possible for the JaM Plugin to replicated defects between two QC servers and JIRA? A: Yes! Q: Is there a log level we can set in JIRA to better understand what is going on (the only message we have is: WARN jira.plugin.mercury_kit.MercuryHelper No defects found). A: Yes, you can set the log level to INFO or DEBUG, for either all of JIRA or just for the package com.go2group.For example: log4j.category.com.go2group = DEBUG, console, filelog, R Q: Logging in MercuryInterface is not explicit enough (Adding bug XX doesn't say in which direction it's adding the bug). A: That particular message occurs when it is returning a list of defects that were updated after a certain time. We've since make the log messages a bit more explicit - please ensure you are running the most recent version of the JaM Plugin. Q: When creating a new issue in JIRA, a blank due date will generate a parse error and prevent the issue being replicated. A: We have not been able to replicate this issue internally. Please ensure you are mapping due date to the proper field. Q: If a tester is updating a bug and a developer is updating the same issue at the same time, what happens? A: JIRA updates win over QC updates in the case of simultaneous edits. Q: Does the JaM Plugin do any project mapping between QC and JIRA? A: Yes, JaM uses mappings between projects in QC and JIRA. Q: After installing the JaM Plugin, the Linked Issues field in Quality Center's Test Case does not update automatically when the JIRA issue is updated. It seems QC can only add linked issue to it but not remove or update. Is this correct? A: Yes. The JaM Plugin supports updates in most cases. The only case where it doesn't update properly is when there is only one JIRA issue tied to a test case, and that link is removed. The current solution is for the user to manually delete the reference to the JIRA ticket in QC. We are currently exploring a method of solving this issue programmatically without impacting the performance between QC and JIRA. Q: When removing an old project from the properties file and replacing it with a newer one (i.e. the old project no longer needs to be replicated), a Connection Reaper message appears (see below). Customproject2 is the old project and customtestabi is the new one. Why is there still a reference to Customproject2? 5530102 [Connection Reaper] DEBUG com.go2group.mercury.MercuryInterface - checking connection for key fsgsydapp39:8080/qcbin-jiraqc-DEFAULT-customtestabi 5530102 [Connection Reaper] DEBUG com.go2group.mercury.MercuryInterface - checking connection for key fsgsydapp39:8080/qcbin-jiraqc-DEFAULT-Customproject2 A: The connection to Quality Center is cached for performance reasons. The log line in question is checking the connection to that project, and likely removing once it times out. Q: I have entered data into QC, but the fields are not being copied to JIRA following a sync. What could be causing this? A: There are a few reasons this could be happening. One thing to check is the lasttime.txt file (see in Common Properties Configuration image, under Go2Group JaM Plugin, Configuration) - be sure the path to the lasttime.txt file is correct. If the problems remain, please open a ticket on our helpdesk system and attach the requested log files (see above). Q: Does the Go2Group JaM Plugin support multiple JIRA projects? A: Yes! The configuration is easy - simply create a custom field in Quality Center, then provide a list of JIRA Project Names in the custom field. Once completed, configure the JaM Plugin according to the mapping needed for these projects. Q: I am receiving the error "java.io.FileNotFoundException: #lasttimefile (No such file or directory)". What's going on? A: It looks like the lasttimefile has not been configured correctly. Here's what we can do to fix this error...
Q: The attachment has the wrong URL - when I click on the attachment, it refers to an incorrect URL location. A: We need to update the JaM configuration to ensure the URL is correct:
Q: How does the Go2Group JaM Plugin cope with errors? A: To view errors, a text free custom field can be created in JIRA and configured within the JaM Plugin. This will allow any errors during the replication process to be visible within this JIRA custom field. To quickly resolve any errors during replication, we ask for a few log files to more quickly discover the source of the error. These files include:
Once gathered, these files can be attached to a ticket on the Go2Group support site at: jira.Go2Group.com. Please note, the JIRA site is a self-managed site. If you do not have an account, feel free to create one as needed. Additional support information can be found here. Q: If the JaM Plugin discovers an error, does it retry the entire synch from the last successful update? A: If an error occurs from JIRA > QC (ie, a QC defect is created from a JIRA issue), the JaM Plugin will automatically attempt to sync again during the sync. However, if an error occurs when a JIRA issue is updated, the JaM Plugin will not attempt a re-sync. Since users might have updated the corresponding defect in QC, the JaM Plugin does not attempt to overwrite the recently updated data. Q: How often does the JaM Plugin attempt to retry a failed attempt? A: The Go2Group JaM Plugin synch schedule is dependent on the configuration of the MercuryService service. The most frequent delay is 1 minute. See the installation guide for additional details. Q: Does the JaM Plugin provided any locking during synchronization? For instance, upon a sync, are users allowed to continue editing a synced issue/defect? If so, will these changes be picked >up in the next scheduled sync? A: The JaM Plugin doesn't lock any JIRA issues or QC defects during replication. QC does have a locking mechanism for defects, which the JaM Plugin abides by. If a user updates a QC defect while the JaM Plugin attempts to sync, there may be an error since the defect is locked by QC while the user is editing the defect. In this case, any changes to this defect will be not picked until the user completes their edits. (Otherwise, the replication may overwrite the values in an incorrect state.) Once the user has completed their edits, the defect will be replicated to JIRA during the next sync process. Q: Where does the data live? A: In general, the Go2Group JaM Plugin simply displays information from QC in a JIRA issue and from JIRA in a QC defect. In more detail, the QC defect/requirement/test case data is cached in the JIRA server. The JaM Plugin only keeps the QC Defect ID in a custom field within the JIRA database. All QC-related data is cached and refreshed according to the configuration. In QC, the JaM Plugin only keeps the JIRA issue ID and attachment links in custom fields within the QC database. This is to ensure the performance of either system (or the network in general) is not affected by large files being synced. The attachments themselves remain in the originating database. When an issue in JIRA is created, then associated with a new defect in QC, the information is then passed to QC and stored in the QC database, just as if the defect was created within QC. Q: Since the data is replicated, have you had cases where the two databases get "out of sync"? How do you fix them when that happens? A: The Go2Group JaM Plugin provides two features:
Q: Is there a list of fields that are replicated in the "out of the box" version? A: There are a number of default fields that are included during the installation and initial configuration of the Go2Group JaM Plugin. You can find these fields here.
PurchaseQ: How much does the JaM Plugin cost? A: A 12-month license for the JaM Plugin is priced at USD$1,995.00. The license agreement includes a one-time license fee and 12-months of support and maintenance. Maintenance includes upgrades and updates, and Go2Group support is provided through email, our customer-focused JIRA instance, and by telephone where needed. Q: Is there an End User License I need to agree to before using the Go2Group JaM Plugin? A: Yes. Please review and agree to the End User License Agreement before using Go2Group products. Q: Can I renew my support agreement after the initial 12-month period concludes? A: Yes, you can renew your support agreement for an additional 12-months for a fee of USD$995.00. The renewed support agreement will give you access to upgrades and updates, and Go2Group support is provided through email, our customer-focused JIRA instance, and by telephone where needed. Q: How can I purchase the Go2Group JaM Plugin? A: The Go2Group JaM Plugin can be purchased by contacting us. Go2Group accepts purchase orders and all major credit cards. Q: I paid for a license of the Go2Group JaM Plugin - where is it? A: Once payment has been processed by Go2Group, you will receive a production license key for your use. Please note - we do not release these keys prior to processing payment. Q: If for some reason I am not satisfied with the JaM Plugin, can I apply for a refund? A: Go2Group does not offer refunds. Go2Group allows its customers to evaluate the JaM Plugin for a period of 30-days (and beyond where necessary), which allows our customers to determine whether the JaM Plugin will work within their environment. If you have any questions prior to purchasing the JaM Plugin, please contact us. |
