zaine/org_roam
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

adding content

Browse Source
This commit is contained in:
Zaine Arch
2026-04-19 23:11:00 +01:00
parent a5983242f9
commit c79938f1a2
310 changed files with 4169 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

95
Career Concepts/20260410121719-esp_applications.org Normal file
View File

@@ -0,0 +1,95 @@
:PROPERTIES:
:ID: 091e9bbc-0c9f-43da-81f9-464882c2a15b
:END:
#+DATE: 2026-04-10
#+filetags: :esp:ess:microlise:citrix:database:
#+STARTUP: showall
#+title: ESP Applications
* What is ESP?
:PROPERTIES:
:RELATED: [[id:091e9bbc-0c9f-43da-81f9-464882c2a15b][ESP Applications]]
:END:
ESP is a software suite built by ESS and sold to customers. It is deployed on a *per-customer basis* — similar to TMC (another internal product) but with fewer applications in the suite.
Key traits:
- Customers only have the apps *they use* — not every customer gets everything
- Customers may have multiple environments (e.g. TEST and PROD)
- Test and PROD instances may live on the *same server* — this is a risk to be mindful of during deployment
* Application Categories
ESP applications fall into three categories:
** 1. Databases
| Application | Type | Notes |
|-------------+------------+---------------------------------------------|
| EspBroker | SQL Server | The core ESP database. Deployed via dacpac. |
See [[id:46add22d-e562-4e3a-a301-d4aea2552952][ESP — Database & Dacpac]] for dacpac detail.
** 2. Windows Services
[[id:faa7f193-5af6-4a2f-a73e-540f833a7fd0][Windows Services]] are background processes that run on a Windows server. They have no UI — they start, run, and are managed via the Windows Service Manager (or PowerShell commands like ~Stop-Service~, ~Start-Service~).
| Service Name | Notes |
|-----------------+-----------------------------------|
| DLService | Unknown specific function (TBC) |
| EmailService | Likely handles outbound emails |
| ExPlService | Unknown specific function (TBC) |
| MISService | Unknown specific function (TBC) |
| OutboundService | Likely handles outbound messaging |
| ULService | Unknown specific function (TBC) |
*** Working with Windows Services in PowerShell
#+BEGIN_SRC powershell
# Stop a service
Stop-Service -Name "DLService" -Force
# Start a service
Start-Service -Name "DLService"
# Check service status
Get-Service -Name "DLService"
# Wait for a service to stop
(Get-Service -Name "DLService").WaitForStatus('Stopped', '00:01:00')
#+END_SRC
*** Why Services Must Be Stopped Before Deployment
When deploying a new version, the old service process holds file locks on its [[id:e717c252-0e15-4403-898f-93163dd1b147][DLLs]]. You cannot overwrite a locked file on Windows. Therefore the sequence is:
1. Stop the service
2. Swap the files (old → new)
3. Start the service
** 3. Citrix Applications
Citrix is a technology that *streams desktop applications* to users remotely - the app runs on a server but the user sees it on their machine, similar to a remote desktop but on a per-app basis.
| Application | Notes |
|---------------+------------------------------|
| VPlanner | Main planning application |
| VPlannerAdmin | Admin interface for VPlanner |
| ImportApp | Data import application |
*** Citrix Deployment Considerations
Citrix apps are more complex to deploy than Windows Services because:
- *Active user sessions* may be running — you can't just swap files
- You must *notify users* of the upcoming upgrade and give a grace period
- After the grace period, *kill any remaining sessions*
- The actual upgrade mechanism is *still TBC* — believed to be a file copy with handling for locked executables built in
- Post-deploy *cycle checks* require navigating Citrix UI — hard to automate
* Per-Customer App Lists
Unlike TMC (where presumably all customers get everything), ESP is a subset deployment. This means:
- The manifest (see [[id:9bf19a8b-5581-4be8-9892-913c51df0128][ESP — The Manifest]]) must define *which apps each customer has*
- The deployment scripts must skip apps not applicable to a given customer
- There is no universal "deploy everything" - each customer's list must be explicitly defined and maintained
* Completeness of This List
:PROPERTIES:
:STATUS: Unconfirmed
:END:
The handover document states this list is believed complete but *has not been confirmed*. Treat it as a working assumption, not a guarantee. Validate against actual customer environments when possible.