Introducing Farrenio Cloud Control: your whole SAP estate in one console

A team of four Basis administrators covering a dozen SIDs is an ordinary staffing level, not an understaffed one. What it produces is a working day that begins with the same sequence of SAPGUI sessions, opened one host at a time, to establish whether anything needs attention. The systems stay available, so the arrangement rarely comes under review.

Farrenio Cloud Control replaces that sequence with a single console covering every system in the estate. This article describes what it reads, how it reaches your hosts, what it will run on your behalf, and the boundaries we have set on it.

What general-purpose monitoring cannot see

Infrastructure monitoring handles CPU, memory and disk perfectly well, and there is no reason to replace it. Its limitation is that it has no view inside SAP. It cannot report that SM50 shows every dialog work process sitting in PRIV mode. It will not tell you that ST22 has taken forty TSV_TNEW_PAGE_ALLOC_FAILED dumps in an hour, that an SM37 chain terminated with status cancelled at 02:14, or that a delta merge has not run against a table the business depends on.

Those signals only exist inside the application. Without them you are monitoring the server rather than the system running on it, which is why an estate can look entirely healthy on an infrastructure dashboard while a Basis administrator would recognise a problem within seconds.

The firewall question

Security review normally opens with what needs to be permitted inbound, and a fair number of monitoring evaluations end there. Requiring an inbound rule to a production SAP host commits the customer to a change request, a risk assessment, and a justification at every subsequent review.

Our collector avoids that entirely. It is a lightweight Python daemon installed on each SAP host, querying the local system through the interfaces an administrator already uses: RFC to the ABAP stack, sapcontrol at the instance layer, SQL against HANA where licensing allows, and the operating system underneath. Collected data leaves the host outbound over HTTPS on 443. Nothing connects inward, so there is no firewall exception to negotiate and no VPN or bastion to maintain. Engineers on call do not need SAPGUI installed to see what is happening.

Installation is a script and a token. Each agent then reports its own health on a rolling 30-day timeline, which matters more than it might appear: a monitoring platform that stops collecting without saying so leaves you worse off than having none, because you continue to trust a view that is no longer being updated.

Coverage by layer

Keeping these on one screen is what makes them useful. A response-time increase in ST03, a filesystem at 96 per cent and a transport imported forty minutes earlier form a diagnosis when you see them together. Held in three separate tools, they are three unrelated observations and an afternoon of work.

Alerts, incidents, and the availability figure you report

Thresholds are set per metric, per system and per customer. A batch window that is entirely normal on one system may be an incident on another, and a single global rule set will either miss real problems or produce enough noise that operators learn to ignore it. Breaches are delivered to whichever channel the team already watches, whether that is email, Slack, Microsoft Teams or PagerDuty, and escalate by severity when nobody acknowledges them. Planned work is covered by maintenance windows.

Where an alert warrants action it becomes an incident with an owner, a priority and a comment thread, and stays that same record until it closes. This is what allows the availability figure to survive questioning at a service review. Uptime is calculated per system with planned maintenance excluded, aggregated across customers, and exported to PDF or Excel. Nobody has to reconstruct events from a chat history several weeks later.

Runbooks, and who remains accountable for them

The other half of the operational workload is procedural: client copies with SCCL, client deletion with SCC5, instance start and stop through sapcontrol, kernel patching, system refreshes, SPAM and SAINT add-on imports. These are already documented, and none of them benefit from being retyped from memory late on a Friday by whoever happens to be available. The platform runs them as guided procedures, validating prerequisites before anything is applied, executing the SAP steps in sequence, and writing each step to the audit trail with the operator's identity and source IP.

These are runbooks that an authorised person starts. They are not autonomous processes deciding on their own to act against production, and that is a position we hold rather than a feature still in development. We have set out the reasoning at more length in a separate article on what machine assistance is and is not good for in Basis work. Anomaly detection and forecasting earn their place by cutting false positives and catching gradual trends that periodic review misses. Responsibility for a production change stays with a named person.

Roles, permissions and the audit trail

Authorisation runs on a 96-permission matrix across eight built-in roles, covering platform owner, administrator, customer administrator, customer, technician, service desk, contractor and support agent. Permissions are delegated through the administration interface, so scoping a role to your own organisation's separation of duties does not require a code change or wait for a release. A service desk user can work through alerts and short dumps all day without the ability to execute a transaction or reveal a stored credential.

Beneath that sit TOTP multi-factor authentication, encryption at rest for SSH and RFC credentials, and an append-only audit trail recording every privileged action along with each sign-in, its source IP and device. Retention is 365 days for authentication events and 180 for everything else, and the log can be pulled through an API into your SIEM. Where the platform is run multi-tenant, customer data and audit records stay isolated, which is a hard requirement for partners managing several clients from one console.

What it does not do

• It will not replace SAPGUI. Configuration, development and the long tail of SAP transactions belong there, and the platform covers the operational subset a Basis team works in daily.
• It is not an APM product. You will see that response times degraded and what else moved at the same time, but tracing an individual ABAP call stack is a different category of tool.
• Automation will not act on its own initiative.
• Licensing is per system, not per user. A single SID, a landscape of up to six, or an estate scoped against your inventory, with unlimited accounts on every tier so that read-only access never has to be rationed.

Trying it against a system you already know

There is a screen-by-screen tour of the console if you would rather look than read. The more useful exercise is to install a collector against one SID you understand well, then judge the platform on your own SM37 records, ST22 dumps and HANA tenants rather than on a demonstration dataset.

If any of the above matches your own environment, write to contact@farrenio.com and we will set that up against a system of your choosing.