Application Links Troubleshooting Flowchart

Check the server.xml file for each application. Look for the following indicators:

• Does the application listen on a different port than what users access?
  • By default port 80 is used for HTTP connections, and 443 for HTTPS connections
• Does the application have a proxy defined in a HTTP connector?
  • Look for the proxyName, proxyPort and scheme attributes in a Connector element

  • As of Bitbucket Server 5.0, you can't configure any Tomcat connectors directly.

    server.xml configurations have been replaced by <Bitbucket home directory>/shared/bitbucket.properties

    Please read through Migrate server.xml customizations to bitbucket.properties to check the corresponding properties.

     

• Does the application have an AJP connector defined?

The Base URL for each application should be set to what users will access. If it is not, update the Base URL for each application to the correct value.

The "Display URL" for the local Application should match the base URL for the remote application. If it does not match, adjust it so that the "Display URL" uses the correct base URL. You do not need to recreate the Application Link - the "Display URL" is editable through the Application Link configuration screen.

If the local "Application URL" value in the Application Link does not match the remote base URL, you must delete and recreate the Application Link. You cannot edit the "Application URL" value in the Application Link configuration dialog.

You must have an unproxied connector in this scenario. See Data Center How to bypass a reverse proxy or SSL in Application Links for more information.

If the local "Application URL" value in the Application Link does not match the unproxied connector, you must delete and recreate the Application Link. You cannot edit the "Application URL" value in the Application Link configuration dialog.

The authentication settings used in the application link must be symmetrical. Ensure that:

• Only one type of Authentication is selected in the local application's "Outgoing Authentication" configuration
• The settings are identical in the remote application's "Incoming Authentication" configuration

You should ensure that the local and remote applications are using a Network Time Server so that the system clocks are correct and in sync. This will help to reduce the possibility of a certificate expiring in transit between the two applications.

If your operating system has updates to time zone definitions, you should ensure these updates are installed. This helps to ensure that each application can correctly identify the time zone, and the offset used in that time zone.

In some cases, the remote API must be enabled for certain cross product functionality. This includes (not is not limited to)

• JIRA Service Desk providing search results from a Confluence Knowledge Base space
• JIRA Issues linking to Confluence Pages
• Displaying Bamboo plans and projects in gadgets
• Displaying Stash repositories from the "Source" tab in JIRA

If some (but not all) functionality between applications fails, try enabling the remote API in each application.