job-commission-set-payable
Console job that triggers Phenix commission line status updates, marking commission payable either for all bookings at the present date or for a single specified booking.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | TC.MaintainanceTools.SimpleJobs 6, TC.ConnectionBroker 1.19 |
| Runtimes | .NET Framework 4.7.2 |
| Tests / CI | some / CI in place |
| Last commit | 2025-12-10 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Payments and finance (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 2 release pipeline(s): \finance\jobs\job-commission-set-payable Dev; \finance\jobs\job-commission-set-payable Release |
| Integration | wcf |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Speaks WCF (client)
Detaches when its WCF surface gains a modern interface or its WCF calls move to one.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Needs workFeasible through the Workflow Engine's rolling drain, but real preparation is needed: dual-version discipline, better tests, or schema care before at-will release is sensible. Legacy runtime: the rolling drain works (stealth releases prove it) but relies on fix-forward risk rather than dual-version safety.
- Consumes WCF contract packages: never take a breaking client bump mid-feature, and treat obsolete warnings as migration debt
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Feasible after replatformingAppropriate, but the .NET Framework runtime has to go first; container work rides along with the replatform rather than preceding it.
- .NET Framework only runs on Windows; practical (Linux) containers need modern .NET
- Replatform to modern .NET first (see the recommended actions). Containerising then becomes routine.
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
- Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.
Recommended actions
Replatform job-commission-set-payable to modern .NET
Runs on .NET Framework 4.7.2, out of mainstream support. No pinning dependency blocks it; sequence by fan-in (providers before consumers).
Impact: Reduces the end-of-life runtime count
proposedAssessment notes
job-commission-set-payable
Purpose
A thin scheduled console job (TC.MaintainanceTools.CommissionLineStatusUpdate) that calls the Phenix booking service to perform commission line status updates, i.e. set commission payable. It runs across all bookings at the current date by default, or a single booking when a BookingId setting is supplied.
Tech stack
- C# console app targeting .NET Framework 4.7.2 (
net472) with SDK-style csproj, modern LangVersion 14 and nullable enabled viaDirectory.Build.props, plus a broad analyser suite (Sonar, NetAnalyzers, SecurityCodeScan). - Uses the in-house
TC.MaintainanceTools.SimpleJobsframework with web/app.config configuration,TC.ConnectionBroker.Wcffor environment-aware connectivity,TC.Phenix.Services.Client8.0,TC.ContactCentre.ServiceClient, and SimpleInjector for DI. - Per-environment
app.*.configXDT transforms (testqa, datafixqa, opsdev, liveproviderqa, preproduction, production).
Deployment
Prod application with 2 releases. Build pipeline job-commission-set-payable (classic-style build.yaml: VSBuild/VSTest on a Windows agent, XDT transform script, zip artifact) feeding release pipelines \finance\jobs\job-commission-set-payable Dev and \finance\jobs\job-commission-set-payable Release.
Dependencies
- Internal NuGet packages:
TC.Phenix.Services.Client,TC.ConnectionBroker.*,TC.MaintainanceTools.SimpleJobs.*,TC.ContactCentre.ServiceClient,TC.Exceptions.WebApiClient. - Git submodule
deployment-scripts(build-time only; that repo is not in the deployed-repos inventory, so it is not listed as an internal dependency). - Third-party: SimpleInjector.
Data stores
None accessed directly; all commission updates happen inside Phenix via the booking service facade (PerformCommissionLineStatusUpdates).
Integration points
- WCF calls to the Phenix booking service via
TC.Phenix.Services.Client.BookingServiceReferenceoverTC.ConnectionBroker.Wcf.
Code health
- Small codebase with an MSTest test project (
SetCommissionPayableTests) run in CI via VSTest. - CI is an older Windows-agent YAML pipeline (NuGet restore + VSBuild + XDT transforms) rather than the shared dotnet templates used by newer jobs.
- Recently touched: last commit 2025-12-10.
Modernisation risks
- Runs on .NET Framework 4.7.2, requiring Windows hosts and MSBuild/VSTest build agents; a candidate for the same .NET 8 migration already applied to sibling jobs such as job-close-bookings.
- WCF client dependency on the Phenix booking service ties it to that legacy service surface.
- Config management via XDT transforms and app.config bindingRedirects adds friction; otherwise logic is trivial and low risk.