The Collabora application already speaks our protocol.

EGroupware ships a Collabora application in its distribution, and that application is a WOPI host. Give it the SumOffice address instead and the documents open in our engine — configuration only. Measured: a macro workbook and a document with five pictures went the full round and came back with the VBA and the pictures identical.

What was measured, and the trap

The round	`.xlsm` and `.docx` opened from EGroupware, edited, saved back. VBA byte for byte, five pictures byte for byte.
It reads only the first zone	A discovery document can declare several network zones. EGroupware takes the first one and ignores the rest — so the zone order in the document decides whether it works at all. Ours is arranged for that.
It caches a failure for an hour	If the editor is not up yet when EGroupware first asks, it remembers the failure and does not ask again for an hour. Start the editors before you save the address, or plan to wait — this is the single most confusing thing about the setup, because everything looks correct and nothing happens.
What this does not say	The round used a fixture workbook from our corpus that asks Microsoft Excel to repair it on its own, before any round — so no silent-Excel claim here. See Nextcloud and Seafile.

Setting it up

# 1. start the editors FIRST — see the caching note above
git clone https://github.com/SumOfficeApp/sumoffice-docker && cd sumoffice-docker/nextcloud
cp env.example .env    # PUBLIC_URL=https://office.example.com
docker compose up -d
curl -s https://office.example.com/hosting/discovery | head -c 300   # must answer before the next step

# 2. EGroupware → the Collabora application → server address
#    https://office.example.com

Evaluation is free with no time limit; production is the per-application license. The other systems we measured →

Then

Check my Excel file — what your workbooks rely on, in seconds.
Tell us your EGroupware version and we will say plainly whether we fit it.