Laravel development for Abu Dhabi entities and energy groups

An Abu Dhabi engagement is usually not a conversation with the end client. It is a contract with the integrator who holds that conversation, building a system an entity will keep for a decade.

The people paying are entities, utilities, energy groups and sovereign-backed companies. What they need from a backend is less about scale than about provability - the data has to be correct in Arabic, the integrations have to be able to show what they sent, and the system has to be maintainable by whoever is holding the contract in five years.

In Abu Dhabi the Arabic name is the legal name

This is the schema decision that separates a system built for Abu Dhabi from one adapted to it.

The usual pattern, arriving from elsewhere, is a name column holding a Latin transliteration, with an Arabic field added afterwards as an optional extra. That has the relationship backwards. If the Arabic name is the legal one, it is the authoritative column - not nullable, not secondary - and the transliteration is the convenience field that may be absent.

Getting this the wrong way round produces two lasting problems. Reports and exports default to the transliteration, which is not the name on any document. And because the Arabic column was added later, it is frequently given the wrong collation, so sorting a list of names produces an order that looks arbitrary to anybody who reads Arabic. Both are migrations across every related table once there is data.

An Abu Dhabi submission is not done until the receipt is stored

Government platform integrations have a property that ordinary API work does not: somebody may later ask you to prove what you sent and when.

That rules out treating the HTTP response as the record. The pattern that holds is a submission row written before the call, a reference generated on our side so the platform can reject duplicates, and the platform's receipt stored as data the moment it arrives. Anything without a receipt is incomplete and retried; anything with one is never sent again.

The failure this prevents is the expensive one. A request that timed out after the platform accepted it, retried in good faith, becomes two filings and a phone call. Laravel's queue will retry by default, which makes being safe to run twice a requirement here rather than a nicety.

Certificates expire, and Laravel will not warn you

Integrations here are commonly authenticated with a client certificate rather than a token.

The code difference is small. The operational difference is that a date exists, somewhere, after which a working integration stops working, and that date is not in anybody's sprint. The systems that survive record the expiry as monitored data and support rotating the certificate without a deployment.

It belongs with the rest of the unglamorous operational surface - deploying and running Laravel yourself covers the shape of it, and in this market self-hosting inside approved infrastructure is usually the requirement rather than the choice.

An Abu Dhabi asset register has a hierarchy and a history

A plant is not a list of equipment. It is a hierarchy - a site, an area, a unit, a system, an item - and the tag number that identifies a piece of equipment describes its position in that hierarchy rather than the object itself.

Which produces the distinction that most registers get wrong. A tag is a functional location; the physical item installed there is a separate thing with its own serial number and its own history. A pump is removed for overhaul and a spare is installed in the same position. The functional location is unchanged, two physical assets have moved, and the maintenance history belongs partly to the position and partly to the item. A register with one record per pump cannot express that, and the consequence is a history that follows the wrong object.

Finance has its own view and it will not match. Their asset list is organised around capitalisation and depreciation, with items grouped and valued in ways that have nothing to do with where they are bolted down. Trying to make one table serve both produces something neither side trusts. Two registers with an explicit, maintained mapping between them is honest and workable.

Changes to the hierarchy are events worth keeping. Areas are reorganised, units are renumbered after a modification, and a report run against last year's structure has to still make sense. Effective-dated hierarchy, rather than a tree somebody edits, is what keeps a comparison across years meaningful.

Laravel work orders on an Abu Dhabi plant

Maintenance work is scheduled on two different clocks and a system that knows only one of them is wrong about half the plant.

Calendar-based is the easy clock - inspect this every six months. Usage-based is the one that needs data flowing in - service this after a number of running hours, cycles or tonnes. The second depends on readings that arrive from somewhere else, and the schedule is therefore derived rather than fixed, which means a due date that moves as usage accrues and a forecast that is an estimate until it is not.

Permits gate the work rather than describe it. A job cannot start until the permit to work is issued, the isolation is confirmed and the relevant people have signed, and that chain has to be modelled as a precondition the system enforces. A work order marked in progress against a permit that was never issued is the kind of record that matters during an investigation.

Shutdown windows are the planning constraint that shapes everything else. A large proportion of the work can only happen while a unit is down, the window is fixed months in advance, and the question the planner asks is which jobs fit in it. That is a scheduling problem over a bounded resource, and it needs the work orders to carry honest duration estimates and their dependencies on one another. Where it is left as a spreadsheet, the window closes with work undone - and the next window is a year away.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - the entity question, e-invoicing, free zone against mainland - is on the UAE market page, and the Arabic collation groundwork is set out on the Dubai page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars, by bank transfer, with no Turkish VAT under the export-of-services exemption.