E
dit
A
ttach
P
rintable
r13 - 2023-11-15 - 19:37:48 -
MichaelRowe
You are here:
TWiki
>
Deployment Web
>
DeploymentPlanningAndDesign
>
YouCantChangeThePublicURI
<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%"> ---+!! You can't change the public URI of Jazz-based applications %DKGRAY% Authors: Main.JimRuehlin <br> Build basis: ELM %ENDCOLOR%</div></sticky> <!-- Page contents top of page on right hand side in box --> <sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;"> %TOC{title="Page contents"}% </div></sticky> <sticky><div style="margin:15px;"></sticky> <BLOCKQUOTE> *Update: You CAN change the public URI, but you must use the Server Rename feature.* </BLOCKQUOTE> A lot's happened in Engineering Lifecycle Management (ELM) since I wrote this article. The ability to modify the public URI is one of them. There are some things to be aware of when you're considering this. Please see [[https://www.ibm.com/support/knowledgecenter/SSYMRC_7.0.2/com.ibm.jazz.install.doc/topics/c_redeploy_server.html][this section of the Knowledge Center]] for instructions on the Server Rename feature. ============================================ So, heres the first thing you need to know when performing administrative tasks on Jazz-based products: You cannot change the public Uniform Resource Identifier (URI). You cannot change the root context. Many discussions long discussions have taken place with customers about this, so it's important to emphasize this one thing: Under no circumstances should you change the public URI. Under no circumstances should you change the root context. This instruction is designed to convince you that you cant change the public URI or root context after it has been set during setup. Really. You cant. Just stop thinking about it. You can get around this constraint by using [https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/lifecycle-management/7.0.3?topic=topology-reverse-proxy-servers-in-topologies][reverse proxies]] or [[https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/lifecycle-management/7.0.3?topic=topology-dns-names-in-topologies][DNS names]]. But this does not change the actual public URI or root context. DNS names and reverse proxies just remap the URLs. ---++ You might be thinking: Why cant I change the public URI? Architecturally, Jazz-based products use OSLC and RESTful interfaces. This means that artifacts (data) is referenced with URLs. When a dashboard shows information from a work item, its getting that work item information by traversing a URL. When you get a list of dashboards to choose from, each dashboard is referenced internally by a URL. When a Engineering Workflow Management work item links to a Engineering Test Management test case, it does so through a URL. All those URLs are written into the database. Theyre not dynamically calculated. The actual URL is placed into the database. Jazz-based products construct these URLs by using the public URI and the root context. So if your public URI is: <verbatim> https://my.server.com:9443 </verbatim> and your root context is: <verbatim> /ccm </verbatim> then every URL that identifies information in the database starts with: <verbatim> https://my.server.com:9443/ccm </verbatim> *If you change the public URI or root context, you break all those links.* And your heart will break too. Now you might be thinking: Why not just search and replace the URLs in the database when you change the public URI or root context? Ah, life is not so simple. The table structure in the database is optimized for reads. The result is that item content is often stored as blobs (binary large objects), not simple text. And some resource content is not directly interpretable by the Jazz framework because the data is component specific. The URL in these components might be stored as binary, .rdf, .xml, or another format. So, identifying and replacing the links is not trivial. That said, theres plenty of discussion going on among developers about making public URIs more flexible. Stay tuned. ---+++++!! Related topics: [[DeploymentScenariosPlanning][Deployment planning: Where to start?]], [[PlanningYourURIs][Planning your URIs]], [[MaintainingThePublicURL][Maintaining the public URL]] ---+++++!! External links: * [[https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/lifecycle-management][ELM Information Center]] ---+++++!! Additional contributors: Main.MichaelRowe <sticky></div></sticky>
E
dit
|
A
ttach
|
P
rintable
|
V
iew topic
|
Backlinks:
We
b
,
A
l
l Webs
|
H
istory
: r13
<
r12
<
r11
<
r10
<
r9
|
M
ore topic actions
Deployment
Deployment web
Planning and design
Installing and upgrading
Migrating and evolving
Integrating
Administering
Monitoring
Troubleshooting
Community information and contribution guidelines
Create new topic
Topic list
Search
Advanced search
Notify
RSS
Atom
Changes
Statistics
Web preferences
NOTE: Please use the Sandbox web for testing
Status icon key:
To do
Under construction
New
Updated
Constant change
None - stable page
Smaller versions of status icons for inline text:
Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use.
Please read the following
disclaimer
.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more
here
.