Custom Pages migration checklist
As part of Relativity’s architecture modernization, all custom pages used in RelativityOne will be migrated to run on RelativityOne’s modernized compute platform. In some cases, you may need to prepare custom pages for the migration. This topic describes some of the preparation you may need to perform.
Determining if your Custom Page is affected
There are three potential ways in which Custom Pages may be impacted by this migration:
- Changes to Relativity-hosted assets: If your Custom Page relies on assets which Relativity hosts by default for all Custom Pages, it may be impacted by a reduction in these standard hosted assets. Alternatively, if your RAP contains all of the assets which your Custom Page depends on, these changes will not impact your Custom Page. See Relativity-hosted asset changes for more details.
- New requirements for server-side rendered Custom Pages: If your Custom Page must be rendered server-side (e.g. it contains .NET code), it may be impacted by new requirements for running on RelativityOne Compute. Alternatively, if your Custom Page only serves static content, these new requirements do not apply. See Server-side requirements for more details.
- The method for accessing Relativity’s main window from a popup has been modified. If your Custom Page (or parts of it) can open as a popup, you may need access to the Relativity main window with something other than window.top. See the topic how to find the Relativity main window from your custom page for guidance.
- ASMX services and WebMethods will no longer be hosted by Relativity, instead essential functionality is available in Relativity's Platform APIs and Relativity Applications' Kepler Services.
|Be stateless||The current web-server based architecture relies on a "sticky session", which means that once a user logs into Relativity all subsequent web requests are always routed to the same running instance of your Custom Page. Once Custom Pages are hosted in the new compute platform this behavior will no longer occur. Your Custom Page must be stateless because the request to your Custom Page may be served by multiple instances during the same browser session and your application could be terminated during auto-scaling operations, node maintenance, or an underlying infrastructure outage.|
|Do not rely on ASP.NET Session State||ASP.NET session state is no longer supported in the new RelativityOne compute platform. Custom pages should be refactored to remove ASP.NET session state dependencies.|
|Tolerate cold in-memory cache hits||The removal of sticky sessions means that Custom Pages which rely on in-memory caching may have adverse impacts. For example, in-memory caching of items related to the logged in user may result in more cold cache hits since multiple requests from the same user are no longer guaranteed to go to the same instance of the Custom Page. Custom Pages must ensure they continue to function correctly despite the loss of sticky session and an increase in number of cold cache hits. Custom Pages that are negatively impacted should consider an alternative caching solution.|
|Do not have multiple Custom Page zip files||Each application in the new architecture may only have a single zip file of Custom Page code. If your application contains multiple Custom Page zip files, they must be combined into a single zip. This does not prohibit you from having one application contain multiple pages on the Relativity User Interface - it simply means that the code for those pages must exist in a single zip file.|
|Do not use SignalR||SignalR will not be supported in the new RelativityOne compute platform. Custom Pages should be refactored so that they do not rely on SignalR.|
|Do not assume admin permissions on the container||
Custom Pages will be hosted under the Windows user with a reduced number of permissions. If your Custom Page relies on admin permissions in Web Servers, it must be adjusted to cater to the reduced permissions noted below:
Note: This only applies to the permissions of the Custom Page on the container. This does not impact end user permissions accessing the Custom Page.
Frequently Asked Questions
Multiple paths exist for developers to make these updates, and, depending on the complexity of your Custom Pages, certain steps may be more significant for you than others. However, below is the general workflow we suggest using to ensure your pages are ready for migration:
Review the requirements listed on this page in detail, and evaluate them against each of your Custom Pages. You should have a good understanding of which Custom Pages will be affected and the approach that you want to use in making them ready for migration.
Make any required changes using your existing development process. Typically, this will be on a DevVM where you can quickly iterate and test. You should also confirm Relativity Logging is implemented and correctly capturing important messages from your agent.
Fully test the behavior of your Custom Pages to ensure it is working as expected.
Install your Custom Page into an EA Sandbox environment and request for it to be migrated to Kubernetes if it is not already migrated. Fully test your Custom Page running in Kubernetes, especially keeping an eye on logging, performance and functional correctness.
Return to Step 2 as needed, based on your findings while running in Kubernetes.
Note: A new DevVM image with all new JS APIs is available – see this developer community post for more information.
Yes, MVC is still supported and does not require ASP.NET Session State.
Yes, these helpers will remain unchanged and may still be used to get information about the user.
Yes, the new APIs will be available on shortly on DevVM – we will update this page once the new image is available. In order to fully test your Custom Page running on RelativityOne Compute, though, you should have your page migrated on an EA Sandbox instance as this is the only way to fully validate functionality with all new changes.