SedonaWeb Legacy
You have to set up more than one instance if you want a different site because it is built strictly in IIS and does not offer separate sites with web.config. Set up redirects are free but the URL in the address bar will be the same. Only a select few customers do this but there is no harm because it is a simple site and all the work is done to the DB directly.
I don’t know that this was/is billed but any new requests should be at minimum a new project to deploy the site especially if hosted.
SedonaWeb 2.0/API
Customers with the same site but different endpoints
The design, per Development, was if you want different sites for different company databases (separate companies in the SO drop down) then you can add companies and have them differentiated by *endpoint*.
Example Customer named PlainOleSecurity has Sedonaweb 2.0 site
Host Site is -- https://PlainOleSecurity.sedonaoffice.com:4433/Account/Login.
Main customer portal -- https://PlainOleSecurity.sedonaoffice.com:4433/portal/ (for payments and account management and usually also API for that company).
Let’s say they have another company database called NewSuperSecurity. They would log in to the host site above and create a new endpoint called https://PlainOleSecurity.sedonaoffice.com:4433/super/
NOTE: This would be its own company endpoint and users but the base URL is the same and this can be done at no cost as it is built into SW2.0 and support has the information to instruct the customer.
Customers wanting to differentiate the base URLs to entirely new sites
(Do not want the visibility of the original) despite the endpoints serving the desired functionality, will require new full deployments of SW 2.0/API. Some customers also want separate sites for API/X and the Customer portal.
This results in:
- A separate deployment in Octopus for each site
- A new SedonaCloud database for each site that has to be specially configured to not clash with the original/default
- Each time they upgrade SO, they need multiple API pushes for each deployment in Octopus
- The customer has to manage Administration of host user credentials for each site
- The customer also has to remember which (if any) they are using other services such as API or Sedona-X because they technically all will work but create a mess of the logs when Support is trying to drill down issues
- For larger customers if they have multiple 2.0 and API /Sedona-X sites there is also likely a need for both the Web Server and SQL server to need more resources depending on if they are doing more than online customer management which isn’t accounted for in the installation or website
- Hopefully the domain is the same for all of them otherwise that adds an additional vector they need to monitor yearly
With the way things are today, it is more efficient for customers with SedonaWeb 2.0 to create a redirection URL for additional branches in conjunction with the endpoint system. Since SedonaWeb 2.0 already has redirection when logging in, that may also pose a problem for browser security in the near future.
From a sales standpoint – I have been recommending these requests are a brand new SedonaWeb2.0 deployment because it takes the same amount of time/work to deploy. You are simply exchanging the pre-requisite portion of the original configuration with the special configuration and repointing of the new unique SedonaCloud database and Octopus tentacle.
Additionally, if customers (like NAS) who have 4-5 different branches all from the same database and want a unique URL for each branch, they need to have multiple deployments.
