Application Links Troubleshooting Flowchart

The following flow chart should be run against each application in turn. Check both applications before proceeding to the next checkpoint. See Flowchart Questions for more in-depth documentation on each checkpoint.

applinksflow

Terminology

  • "Local" refers to the application you're currently checking
  • "Remote" refers to the other application.

Both applications involved will be treated as the "Local" and "Remote" applications during the troubleshooting process.

Flowchart Questions

Is there a reverse proxy in front of this application?

Click here to expand...

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?
  • Does the application have an AJP connector defined?

Is the base URL correct?

Click here to expand...

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.

Does the local "Display URL" match the remote base URL?

Click here to expand...

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.

Does the local "Application URL" match the base URL of the remote application?

Click here to expand...

This only applies if you are not bypassing the reverse proxy.

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.

Does the Local Application URL match the unproxied URL of the remote application?

Click here to expand...

This only applies if you are bypassing the reverse proxy.

You must have an unproxied connector in this scenario. See 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.

Confirm all local "Outgoing Authentication" settings match remote "Incoming Authentication" settings

Click here to expand...

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

OAuth Notes

These notes only apply to Application Links using OAuth

  • The "Execute As" option is only available on the "Incoming Authentication" screen
  • The "Allow user impersonation through 2-Legged OAuth" option is only available on the "Incoming Authentication" screen
  • If you tick "Enable outgoing 2-Legged OAuth requests" in the local application, you must tick "Allow 2-Legged OAuth" in the remote application.
  • If you tick "" in the local application, you must tick "Allow user impersonation through 2-Legged OAuth" or specify a user in the "Execute As" field
  • If you do not tick or specify any of the 2-Legged OAuth options, 3-Legged OAuth will be used instead.

Confirm Time is Synchronized via Network Time Protocol (NTP)

Click here to expand...

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.

Confirm the remote API is enabled

Click here to expand...

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.

Last modified on May 2, 2017

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.