We sometimes get the question how an existing Portal that has been published to Staging and Live Runtimes can be taken offline.
Well, just deleting a Portal from the Project in the Modeler does NOT take it offline in the Runtimes.
A little background first
- Understand that the Modeler and the Runtimes are different and separated environments.
- Information in the Modeler (including portals and their hostnames) is managed in the Modeler and published to Runtimes (Staging and Live). The Runtime Environments get their information from the Modeler ONLY via the Publish Process - otherwise there is no direct link between these environments.
- Deleting information from the Modeler does not immediately or automatically delete information on the Staging and Live Runtimes - changes have to be published to become available on the Runtimes.
- But, when a Portal is deleted in the Modeler, it can no longer be published. So it stays in the Runtimes and can no longer be changed.
- For Publishing and running a portal in Staging or Live, the Portal ID and the Hostname(s) are the key values to setup (for new portals) and access (for existing portals) the correct containers to put the portal assets into (flows and pages and all that makes your project work).
Now, how CAN you take a portal offline then?
- What you need to do to take a portal offline, is to first change the Hostname to something that will not be known or used, and publish that change. This will make the existing hostname no longer linked to your portal because it is replaced by the new hostname and users or applications using the old hostname will receive a HTTP 404 Not Found result. In this case it does not even matter that the new hostname you use has a correct CNAME record (see this documentation on custom hostnames).
- Next or other thing you can do, is to set the Navigation Items Visible/Accessible When expression all to false, to block access to any of those navigation items - which may be used as entry-points into the portal, specifically the Navigation Item that is used as Homepage setting on the portal (the general entry point). This will result in HTTP 403 Forbidden result - which you can also capture using the Custom Error Handler for Unauthorized to present a more friendly page if you'd like (in which case, the hostname should be valid ofcourse). Then also publish this change to make it available in the Runtimes.
This should be enough to have your portal unavailable, unaccessibal, unusable, seemingly offline - while still keeping the files and database in place, just in case you want to revive it later.
Really Definitely Remove Portal
If you really want to get rid of your portal and all files AND the database with all runtime data, you can send in a Support Ticket in MyWEM to let WEM HQ manually remove your portal, the files and the database from the Runtime Servers. WEM HQ will need to know the Portal ID and the hostname(s) to make sure the correct portal will be removed.
Understand that this will be a definitive and unreversible action.
Sidenote: on WEM Private Cloud Kubernetes Runtimes there are other options to manage access and availability to portals via the DevOps Portal features. For those projects you can choose to NOT publish DevOps settings in the Portal Manage Hostname settings, but have those settings (hostnames, https, ip-restrictions and other infrastructural settings) be managed via the DevOps Portal. The responsible DevOps operators can manage those settings for your portal directly on the Runtime Environment.
Ralph - WEM Xpert since 2011
"I speak to machines with the voice of humanity"
-- Marillion, Man of a thousand faces --