Fluke MET/TEAM¶

Integration mit Fluke MET/TEAM Kalibrierungsmanagement-Software.

Uebersicht¶

calServer V2 bietet eine Integration mit Fluke MET/TEAM, einer weit verbreiteten Software fuer das Kalibrierungsmanagement. Die Integration ermoeglicht den Datenaustausch zwischen beiden Systemen.

Funktionen¶

Funktion	Beschreibung
Datenimport	Geraete- und Kalibrierdaten aus MET/TEAM importieren
Erstmigration	Den ganzen MET/TEAM-Bestand einmal uebernehmen (`metteam:migrate`)
Datenexport	calServer-Daten nach MET/TEAM exportieren
Feldzuordnung	Konfigurierbare Zuordnung der Datenfelder
Synchronisation	Periodischer Datenabgleich

Einrichtung¶

Voraussetzungen¶

MET/TEAM-Version und Zugang

Die Integration erfordert MET/TEAM ab Version 3.0. calServer spricht die MET/TEAM-Datenbank auf dem Microsoft SQL Server direkt an; noetig sind eine Netzwerkverbindung zum SQL Server und eine SQL-Anmeldung auf der MET/TEAM-Datenbank. Fuer die Erstmigration genuegen Leserechte auf die Tabellen und das Ausfuehrungsrecht fuer MET/TEAMs eigene Hilfsfunktionen (udf_GET_…). Der laufende Abgleich legt Prozeduren, Trigger und Tabellen an und braucht dafuer weitergehende Rechte (siehe Sync-Schnittstelle provisionieren).

Verbindung konfigurieren¶

Navigieren Sie zu Administration > Schnittstellen > MET/TEAM, Reiter Verbindung
Geben Sie die Verbindungsdaten der MET/TEAM-Datenbank ein. calServer spricht den Microsoft SQL Server von MET/TEAM direkt an, nicht eine Programmierschnittstelle:

Feld	Beschreibung
Produkt	MET/TEAM oder MET/CONNECT
Server-Name	Adresse des SQL Servers
Port	Port des SQL Servers
Datenbank	Name der MET/TEAM-Datenbank
Benutzername	SQL-Server-Anmeldung
Passwort	Passwort dieser Anmeldung

Klicken Sie auf Verbindung testen oder Anmeldung testen
Speichern Sie die Konfiguration

Die Produktversion wird ermittelt, nicht eingegeben

Das Feld MET/TEAM-Version ist schreibgeschuetzt. calServer liest die Version aus Flukes eigener Version-Tabelle — bei jeder Anmeldeprobe und bei jeder Provisionierung. Unter dem Feld steht, wann sie zuletzt gelesen wurde.

Bis August 2026 war es ein Eingabefeld, und das ging schief: Auf einem Kundensystem stand dort 3.4.0, waehrend die Datenbank 3.4.1 auswies. Das ist kein Anzeigefehler — calServer V1 verzweigt auf diesen Wert (version_compare gegen 3.0.0 bzw. 3.4.0), ein veralteter Eintrag schaltet dort also stillschweigend anderes Verhalten.

Zeigt das Feld noch nichts, hatte calServer die Gegenseite noch nie erfolgreich gelesen — einmal Anmeldung testen genuegt.

Zwei Proben, zwei Fragen

Verbindung testen fragt, ob der Server antwortet, und meldet seine Version. Anmeldung testen ist die Probe auf den echten Kontakt mit MET/TEAM und geht in drei Stufen:

Gelesen	Beantwortet
`SUSER_SNAME()`, `USER_NAME()`	Als wer fuehrt der Server die Sitzung?
`DB_NAME()`	In welcher Datenbank ist sie gelandet?
Flukes `Version`-Tabelle	Steht dort wirklich MET/TEAM, und darf dieser Login dessen Tabellen lesen?

Die dritte Stufe ist der Punkt. Die ersten beiden beantwortet der SQL Server fuer jede beliebige Datenbank; erst die gelesene Produktversion belegt, dass hinter dem Login eine MET/CAL-Datenbank steht. Bleibt sie unlesbar, meldet die Probe trotzdem Erfolg (die Anmeldung hat ja funktioniert), sagt aber ausdruecklich dazu, dass der Kontakt nicht belegt ist, statt ihn zu behaupten.

Scheitert sie, sagt sie in Klartext, woran: abgelehnte Anmeldedaten, nicht freigegebene Datenbank, nicht erreichbarer Server, Zeitueberschreitung, Zertifikat oder fehlender Treiber.

Beide Proben speichern nichts. Ist das Passwortfeld leer, pruefen sie das gespeicherte Passwort — die Antwort sagt jeweils dazu, welches der beiden geprueft wurde. Das ist der Unterschied, auf den es beim Wechsel eines Passworts ankommt: Ein gruener Verbindungstest kann auch dann kommen, wenn das neue Passwort noch gar nicht im Spiel war.

Sync-Schnittstelle provisionieren¶

Verbindungsdaten allein synchronisieren nichts. calServer legt in der MET/TEAM-Datenbank zusätzlich seine eigene Schnittstelle an: Stored Procedures, sechs Trigger und die drei Queue-Tabellen Sync, AssetSync und AuditLog2. Fluke liefert davon nichts mit, das ist calServers Anteil. Dieser Schritt heißt Provisionierung.

Drei Voraussetzungen, sonst wird die Provisionierung abgelehnt:

Voraussetzung	Wo
Server-Name, Datenbank und Benutzername gefüllt	Reiter Verbindung
Mindestens eine Synchronisationsrichtung eingeschaltet und gespeichert	Reiter Synchronisation
Login darf DDL: `CREATE PROCEDURE`, `CREATE TABLE`, `ALTER` auf `Assets` und `CallSheets` — oder `db_owner`	im SQL Server

Ein umgelegter Schalter zählt nicht

Die Provisionierung liest den gespeicherten Stand, nicht das Formular. Wer eine Richtung einschaltet und direkt provisioniert, ohne vorher zu speichern, bekommt die Absage „keine Synchronisationsrichtung eingeschaltet". Die Zahl unter „Objekte erwartet" in der Diagnose zeigt dasselbe: ohne aktive Richtung stehen dort nur 13 Objekte, das blosse Grundgeruest.

Wege zur Provisionierung, alle gleichwertig:

Werkzeuge → Diagnose: Findet sie fehlende Objekte, steht „Jetzt provisionieren" direkt neben dem Befund.
Reiter Synchronisation: Ist der Schnittstellen-Stempel veraltet, steht der Knopf in der Warnung oben.
Auf der Konsole:

docker exec calserver-api-v2 php artisan metteam:provision

# Anschliessend die opt-in-Geraete neu einreihen bzw. alle lokalen
# MET/TEAM-Verknuepfungen verwerfen:
docker exec calserver-api-v2 php artisan metteam:provision --action=keep
docker exec calserver-api-v2 php artisan metteam:provision --action=reset

Die Warteschlange in MET/TEAM wird zurueckgesetzt

Provisionieren legt AssetSync und AuditLog2 neu an (DROP und CREATE, V1-Parität). Offene, noch nicht importierte Änderungen aus MET/TEAM gehen dabei verloren. Bei einer Erstinstallation ist das folgenlos; auf einem laufenden System vorher den Import leerlaufen lassen.

Warum das in V1 niemandem auffiel

Im Yii-Adminpanel war die Provisionierung ein Nebeneffekt des Speicherns: actionSaveConfiguration rief sie auf, sobald Server, Port, Benutzername und Passwort gefüllt waren. Einen eigenen Knopf gab es nie. V2 trennt das bewusst — Speichern speichert, Provisionieren provisioniert — weshalb der Schritt beim Umstieg leicht übersehen wird.

Feldzuordnung¶

Die Feldzuordnung definiert, wie Datenfelder zwischen den Systemen abgebildet werden:

calServer-Feld	MET/TEAM-Feld	Richtung
Geraetename	Asset Description	Bidirektional
Seriennummer	Serial Number	Bidirektional
Inventarnummer	Asset ID	Bidirektional
Kalibriertermin	Cal Due Date	Import
Kalibrierergebnis	Cal Result	Export
Standort	Location	Bidirektional
Arbeitszeit (h)	Summe des Arbeitsaufwands im Arbeitsauftrag (Tab „Arbeitsaufwand/Dateien“)	Import

Arbeitszeit

Uebernommen wird nur die Summe aller Aufwandseintraege eines Arbeitsauftrags, nicht wer wann wie lange gebucht hat. Nachtraeglich gebuchte oder geloeschte Eintraege zieht der naechste Abgleich nach. Das Feld setzt eine Provisionierung ab Schnittstellen-Version 12 voraus.

Benutzerdefinierte Felder

Benutzerdefinierte Felder koennen ebenfalls zugeordnet werden, sofern sie in beiden Systemen existieren.

Datenimport¶

Es gibt drei Wege, und sie decken verschiedene Faelle ab:

Weg	Wofuer	Ausloeser
Erstmigration	Den ganzen MET/TEAM-Bestand einmal uebernehmen, etwa beim Umstieg von MET/TEAM auf calServer	`metteam:migrate` auf der Kommandozeile
Laufender Abgleich	Aenderungen an Geraeten mit Sync-Haekchen	Scheduler, alle 15 Sekunden
CallSheets eines Geraets	Einzelne Kalibrierungen eines Geraets gezielt holen	Geraeteansicht, Mehr > MET/TEAM-CallSheets importieren

Erstmigration¶

metteam:migrate liest den Bestand einer MET/TEAM-Datenbank und uebernimmt ihn mit denselben Regeln wie der laufende Abgleich: gleiche Feldzuordnung, gleiche Statusuebernahme, gleiche Zeitumrechnung, gleiche Verknuepfungen. Ein spaeterer Abgleich erkennt uebernommene Datensaetze deshalb wieder, statt sie doppelt anzulegen.

Gelesen wird nur. In MET/TEAM legt die Migration weder Prozeduren noch Trigger noch Tabellen an, das Provisionieren ist dafuer nicht noetig. Die Verbindung kommt aus dem Reiter Verbindung der gewaehlten Instanz.

# Zaehlen, was uebernommen wuerde (liest keine Zeilen)
docker exec calserver-api-v2 php artisan metteam:migrate --list

# Trockenlauf: alles lesen, nichts schreiben
docker exec calserver-api-v2 php artisan metteam:migrate --dry-run

# Uebernehmen (fragt vorher nach, --force ohne Rueckfrage)
docker exec calserver-api-v2 php artisan metteam:migrate

# Nur einzelne Bereiche, eine bestimmte Instanz (Name oder uID)
docker exec calserver-api-v2 php artisan metteam:migrate --module=inventory --module=calibration
docker exec calserver-api-v2 php artisan metteam:migrate --instance='MET/TEAM Werk 2'

# Einen abgebrochenen Bereich hinter der gemeldeten UID fortsetzen
docker exec calserver-api-v2 php artisan metteam:migrate --module=result --after=<UID>

Die Bereiche laufen in fester Reihenfolge, weil jeder auf dem vorigen aufbaut:

Bereich	`--module`	Uebernommen wird
Geraete und Kunden	`inventory`	alle nicht geloeschten Geraete, auch inaktive; Kunden mit ihren Geraeten
Kalibrierungen	`calibration`	alle nicht geloeschten CallSheets nicht geloeschter Geraete
Normale	`standard`	die Normalzuordnungen dieser Kalibrierungen
Standorte	`location`	die aktuelle Zuweisung je Geraet, wie beim Abgleich
Messwerte	`result`	alle Messpunkte dieser Kalibrierungen

Nicht uebernommen werden in MET/TEAM geloeschte Datensaetze, Kunden ohne Geraete und zurueckgegebene Standortzuweisungen (die Historie). Der Statusfilter des Abgleichs (IN-Bedingung) gilt fuer die Migration nicht, sie holt alle Kalibrierungen.

Messwerte liest die Migration CallSheet fuer CallSheet, in der Reihenfolge des Abgleichs: Ergebnislauf nach Anlagezeit, darin die Messpunkte nach ihrer Nummer. Hat ein CallSheet mehrere Ergebnislaeufe (etwa einen zweiten nach einer Justage), stehen in calServer erst die Punkte des ersten Laufs auf ihren Nummern, dahinter die der weiteren Laeufe, so wie der Abgleich sie anlegt. Die UID, hinter der ein abgebrochener Messwert-Bereich fortsetzt, ist deshalb die eines CallSheets.

Waehrend der Migration

Den laufenden Abgleich dieser Instanz fuer die Dauer abschalten. Sonst koennen Abgleich und Migration dasselbe Geraet gleichzeitig anlegen. Der Befehl warnt, wenn der Abgleich aktiv ist.
Den ersten echten Lauf gegen eine Kopie der MET/TEAM-Datenbank machen und das Ergebnis pruefen. Eine Sicherung laesst sich dafuer mit metteam:restore in die mitgelieferte MET/TEAM-Laufzeitumgebung einspielen (Artisan-Kommandos).
Die Migration schreibt Zeile fuer Zeile. Bei vielen Messwerten dauert sie Stunden. Sie laesst sich jederzeit wiederholen; ein zweiter Lauf aktualisiert, statt zu verdoppeln.

Zeilen, die ein Importer ablehnt, stehen im Protokoll mit der Aktion migrate_… und dem MET/TEAM-Datensatz. „Uebersprungen" heisst: Die Verknuepfung fehlt in calServer, etwa bei einem Normal, dessen Kalibrierung nicht uebernommen wurde. Ein zweiter Lauf holt nach, was inzwischen verknuepft ist.

Laufender Abgleich¶

metteam:pull holt alle 15 Sekunden die Aenderungen der Geraete mit Sync-Haekchen aus MET/TEAM. Voraussetzung ist die provisionierte Sync-Schnittstelle; den Takt fuehrt der Scheduler unter Administration > Betrieb. Einzelheiten stehen unter Synchronisation.

CallSheets eines Geraets¶

In der Geraeteansicht holt Mehr > MET/TEAM-CallSheets importieren einzelne Kalibrierungen des Geraets aus MET/TEAM. Uebernehmen verlangt das Recht calibration_edit.

Datenexport¶

metteam:push leert alle 15 Sekunden die Export-Warteschlange nach MET/TEAM, sofern im Reiter Synchronisation der ausgehende Push-Worker aktiviert ist. In die Warteschlange kommen Aenderungen an Geraeten mit Sync-Haekchen, beim Aktivieren eines Geraets auch seine Kalibrierhistorie (siehe Synchronisation).

MET/CAL-Start (Prozedurreferenz am Serviceauftrag)¶

Der Knopf „In MET/CAL starten" an einer Kalibrierung legt bei Bedarf ein MET/TEAM-CallSheet an und uebergibt dessen UID an die MET/CAL Runtime (mcruntime: -w {nCallSheetUID}). Ob MET/CAL danach Geraet und Kalibrierung vorbelegt, entscheidet die Prozedurreferenz des Serviceauftrags (CallSheets.nProcedureUID).

Damit sie traegt, muss die Kette vollstaendig sein:

Ebene	Was dort stehen muss
Workstation bzw. MET/TEAM	Wo die kompilierte MET/CAL-Prozedur liegt, haengt vom MET/CAL-Stand ab: klassisch im Prozedurverzeichnis der Workstation (`procdir` in der `metcal.ini`), auf neueren Staenden als Datei in MET/TEAM an der Prozedur (`Procedures.nProcedureFileUID` → `Files.iFile`). Gefunden wird sie ueber ihre Instrument Line.
MET/TEAM	Eine Prozedur, deren Prozedurname genau diese Instrument Line ist und deren Kategorie „MET/CAL" lautet. Ob „Prozedurdatei" leer bleibt oder die PXE traegt, entscheidet der MET/CAL-Stand (siehe Warnung unter der Tabelle); „Datenblatt" bleibt bei kompilierten Prozeduren leer.
calServer	An der Pruefprozedur ist dieser Name im Feld „MET/CAL-Prozedur" gepflegt (Prozedur-Detailseite, Abschnitt „MET/CAL-Start").

Neuere MET/CAL-Staende starten nur, was in MET/TEAM liegt

Aus dem Feld berichtet (28.08.2026): procdir traegt dort nicht mehr, und eine per Kommandozeile uebergebene Datei (-x) wird nicht mehr angenommen. Startbar ist nur, was in MET/TEAM gespeichert ist — die PXE haengt an der Prozedur, und die verwendete Kalibrierprozedur des Serviceauftrags zeigt darauf.

Dass MET/TEAM das kann, ist belegt statt angenommen: Procedures.nProcedureFileUID traegt einen Fremdschluessel auf Files.nFileUID, und Files.iFile ist varbinary(max). Erhoben gegen die Beispieldatenbanken beider Produkte (MET/TEAM 3.4.0 und MET/CONNECT 2.2.1), dort deckungsgleich; zugesichert in MetteamProcedureFileIntegrationTest.

calServer kann die PXE dorthin uebertragen (siehe naechster Abschnitt). Uebertragen wird die Datei: sie landet in Files, und die Procedures-Zeile darueber zeigt darauf. Ausgeloest wird das von Hand, nicht von der Freigabe. Hintergrund: ADR 2026-08-28 („Die PXE-Vorlage ist die MET/TEAM-Prozedurdatei").

PXE-Vorlagen nach MET/TEAM uebertragen¶

Uebertragen wird jede freigegebene Vorlage vom Typ pxe: sie landet als Datei in MET/TEAMs Prozedurspeicher, und darueber entsteht eine Prozedur in der Kategorie MET/CAL, die auf genau diese Datei zeigt.

Fuer eine einzelne Pruefprozedur steht der Weg in der Oberflaeche: auf der Prozedur-Detailseite im Abschnitt „MET/CAL-Start" unter dem Feld „MET/CAL-Prozedur". Dort steht vorher, unter welchem Namen die Prozedur drueben entstuende und ob MET/TEAM sie schon fuehrt — und was dagegen spricht, wenn etwas dagegen spricht. Der Knopf braucht das Recht procedure_edit.

Fuer den Bestand derselbe Vorgang als Befehl:

# Bericht, uebertraegt nichts
docker exec calserver-api-v2 php artisan procedures:transfer-to-metteam

# und wirklich uebertragen
docker exec calserver-api-v2 php artisan procedures:transfer-to-metteam --apply --force

# eingegrenzt: eine Vorlage, eine Pruefprozedur, eine MET/TEAM-Instanz
docker exec calserver-api-v2 php artisan procedures:transfer-to-metteam --template=<uID>
docker exec calserver-api-v2 php artisan procedures:transfer-to-metteam --procedure=<uID>
docker exec calserver-api-v2 php artisan procedures:transfer-to-metteam --instance='MET/TEAM'

Was dabei gilt:

Der Name. Ist an der Pruefprozedur eine „MET/CAL-Prozedur" gepflegt, steht die Zeile drueben unter diesem Namen — er ist die Instrument Line und damit das, was der Pruefer erwartet. Sonst der Vorlagenname samt Version (DMM 2.3).
Der Name wird zurueckgeschrieben. War das Feld „MET/CAL-Prozedur" leer, traegt die Uebertragung den verwendeten Namen dort ein. Das ist kein Nebeneffekt, sondern der Abschluss: der Serviceauftrag holt seine Prozedur ueber genau dieses Feld, und ohne den Eintrag haette man drueben eine richtige Zeile und hier weiterhin einen Start, der nichts vorbelegt. Ein bereits gepflegter Name bleibt unangetastet.
Je Version eine eigene Zeile. Eine neue Vorlagenversion ersetzt drueben nichts, sie kommt dazu. Ein alter Serviceauftrag zeigt damit dauerhaft auf die Prozedur, die tatsaechlich gelaufen ist — was ein Kalibrierschein braucht. Der Preis ist ein wachsender Prozedurkatalog.
Nur einmal. Steht drueben schon eine Prozedur dieses Namens, wird sie genommen statt eine zweite anzulegen.
Ein Entwurf bleibt hier. Nicht freigegebene Vorlagen und solche, deren Datei im Dokumentenspeicher fehlt, werden uebersprungen und im Bericht benannt — eine Prozedurzeile ohne Inhalt waere Datenmuell im Katalog, aus dem MET/TEAM-Benutzer auswaehlen.
Ausgeloest wird von Hand. Eine Freigabe in calServer schreibt nicht ungefragt in eine fremde Datenbank. Wer es automatisch will, haengt den Befehl mit --apply --force in den Scheduler.

Ohne Kategorie MET/CAL in MET/TEAM bricht der Lauf ab, statt die Prozedur anders einzuordnen: eine falsch einsortierte Prozedur startet die Runtime nicht, und das faellt spaeter auf als ein Abbruch jetzt.

Auf einer uebernommenen Anlage ist die dritte Zeile meist schon erfuellt

MET/TEAM fuehrt am Serviceauftrag, mit welcher Prozedur gearbeitet wurde (dort „Procedure Used"), MET/TRACK dasselbe als Kalibrierfeld. Die Synchronisation bringt diesen Namen mit, und es ist derselbe Wert, den die Pruefprozedur tragen soll.

calServer nutzt ihn deshalb als Rueckfallebene: Ist an der Pruefprozedur nichts gepflegt, startet eine uebernommene Kalibrierung trotzdem mit vorbelegtem Geraet. Fuer neue Kalibrierungen traegt das nicht, die haben kein Uebernahme-Feld. Einmalig nachziehen:

# Bericht, schreibt nichts
docker exec calserver-api-v2 php artisan procedures:backfill-metcal-name

# und wirklich schreiben
docker exec calserver-api-v2 php artisan procedures:backfill-metcal-name --apply --force

Der Befehl ueberschreibt keinen gepflegten Namen. Tragen die Kalibrierungen derselben Pruefprozedur verschiedene Namen, listet er sie auf und schreibt nichts: dann wurde die Prozedur drueben umbenannt, oder es waren fachlich zwei. Welches Kalibrierfeld als Quelle gilt, steht in der Einstellung METCAL_PROCEDURE_FIELD; leer heisst „keine uebernommene Quelle".

Bei einer in calServer durchgefuehrten Kalibrierung schreibt calServer es selbst

Wird die Messwertaufnahme in calServer gestartet — MET/CAL-Start oder die interne Erfassung —, haelt calServer im selben Feld fest, womit gelaufen wurde. Der Kalibrierschein druckt die Prozedurreferenz damit auch dort, wo nichts uebernommen wurde.

Eingetragen wird der gepflegte MET/CAL-Prozedurname; fehlt er, Name und Version der verwendeten Vorlage (z. B. Hausprozedur DMM 2.3). Der zweite Fall ist keine Instrument Line und gibt auch nicht vor, eine zu sein — er beantwortet dieselbe Frage auf der Ebene, auf der calServer sie beantworten kann.

Geschrieben wird beim Lauf und nur in ein leeres Feld. Der Wert ist eine Momentaufnahme: er haelt fest, was damals galt, und bleibt stehen, auch wenn die Prozedurzuordnung sich spaeter aendert. Ein uebernommener Wert wird nie ueberschrieben.

Von sich aus legt calServer in MET/TEAM keine Prozeduren an

Bis August 2026 loeste calServer den eigenen Anzeigenamen der Pruefprozedur in MET/TEAM auf und legte dort bei Nichttreffer eine leere Platzhalter-Prozedur an. Die Runtime konnte damit nichts anfangen: sie sucht die kompilierte Prozedur ueber die Instrument Line, und die stand in diesen Zeilen nie. Der Serviceauftrag trug eine Referenz, das Fenster blieb trotzdem leer — ohne Fehlermeldung.

Das ist beendet. Beim Start sucht calServer die Prozedur nur noch. Fehlt die Referenz oder kennt MET/TEAM den Namen nicht, entsteht das CallSheet weiterhin (es ist der Arbeitsauftrag und traegt Geraet, Nummer und Termine), aber der Start sagt im Klartext, dass MET/CAL nichts vorbelegen kann und warum.

Der Uebertrag oben ist davon nicht beruehrt und widerspricht dem nicht: dort entsteht eine Prozedur nur auf ausdrueckliche Anweisung und nur mit einer Datei dahinter. Genau diese Datei ist der Unterschied zur alten Platzhalterzeile — hinter der stand nichts.

Bestandsanlagen: Die frueher angelegten Platzhalter stehen weiter in MET/TEAM und werden von calServer nicht entfernt — an ihnen koennen fremde Serviceauftraege haengen. Erkennbar sind sie daran, dass ihr Prozedurname einem calServer-Prozedurnamen entspricht, ihre Kategorie leer ist und weder Datenblatt noch Prozedurdatei hinterlegt sind. Wer sie aufraeumen will, tut das in MET/TEAM und mit Blick auf die verknuepften Auftraege.

Die Auswahlliste im Feld „MET/CAL-Prozedur" liest die echte Prozedurliste aus MET/TEAM (nur lesend, MET/CAL-Prozeduren zuerst). Ohne eingerichtete Anbindung oder bei nicht erreichbarem Server bleibt die freie Eingabe — der Name wird dann nicht gegengeprueft, und die Oberflaeche sagt das auch.

Arbeitsstelle: ohne sie startet die Runtime nicht¶

Die Prozedurreferenz entscheidet, ob MET/CAL etwas vorbelegt. Die Arbeitsstelle (CallSheets.nWorkingFacilityUID) entscheidet, ob MET/CAL ueberhaupt anlaeuft. Die Runtime bestimmt darueber den Satz des Auftrags (GetCallSheetRate); steht dort nichts, bricht sie ab:

Das Objekt mit Nullwert muss einen Wert haben.

Ein daraufhin angelegter Ergebnisdatensatz traegt dann auch nProcedureUID, nTechnicianUID und nRunAtFacilityUID leer — die Runtime uebernimmt diese drei vom Serviceauftrag.

calServer belegt die Arbeitsstelle in dieser Reihenfolge:

Reihenfolge	Quelle
1.	Das Kalibrierfeld „Kalibrierstelle" (V1-Code C2313), aufgeloest ueber den Facility-Namen in MET/TEAM. Bei Namensgleichheit gewinnt die als Labor gekennzeichnete Facility.
2.	Die Facility des Geraets (`Assets.nFacilityUID`) — als Rueckfallebene, damit der Start nicht an einem leeren Feld scheitert. Der Startvorgang meldet, dass ersatzweise sie verwendet wurde.

Angelegt wird in MET/TEAM nichts: eine Facility, die es dort nicht gibt, ist eine Pflegeaufgabe in MET/TEAM. Dasselbe gilt fuer den Techniker (nTechnicianUID / nAssignedTechUID), den calServer aus dem Kalibrierfeld „Techniker" aufloest — ueber den Anmeldenamen und ersatzweise ueber „Vorname Nachname". Findet sich kein Benutzer, bleibt die Zuordnung offen; der Start funktioniert trotzdem.

Serviceauftraege aus der Zeit vor August 2026

Bis August 2026 hat calServer die Arbeitsstelle und den Techniker nicht mitgeschrieben — jeder von calServer angelegte Serviceauftrag hatte dort NULL, und genau daran ist der MET/CAL-Start abgebrochen. Bestehende Auftraege werden nicht automatisch nachgezogen. Sie bekommen die Werte, sobald die Kalibrierung das naechste Mal gespeichert wird; einzelne Altfaelle lassen sich so gezielt heilen.

Details zum Startkommando und zu den Runtime-Parametern: Prozedurvorlagen.

Synchronisation¶

Konfliktvermeidung

Bei bidirektionaler Synchronisation koennen Konflikte auftreten. Definieren Sie ein primaeres System fuer jeden Datenbereich.

Die automatische Synchronisation kann ueber die Steuerungen als Cron-Job eingerichtet werden.

Kalibrierhistorie beim Aktivieren eines Geraets¶

Wird ein Geraet in die Synchronisation genommen (Haekchen am Geraet), reiht calServer neben dem Geraet auch dessen vorhandene Kalibrierungen als CallSheets in die Export-Warteschlange ein; Messergebnisse folgen, wenn der Rueckkanal fuer Messergebnisse aktiv ist. So traegt ein frisch markiertes Geraet seine Historie nach MET/TEAM, ohne dass jede alte Kalibrierung noch einmal gespeichert werden muss.

Der Schalter „Kalibrierhistorie beim Aktivieren uebertragen" (Reiter Synchronisation, je Instanz) schaltet das ab — fuer Installationen, die Altdaten nicht nach MET/TEAM spielen wollen. Dann beginnt der Abgleich erst mit der naechsten Aenderung an einer Kalibrierung.

Rueckgabe (CallSheet-Abschluss)¶

In MET/TEAM wird ein Arbeitsauftrag (CallSheet) zurueckgegeben: er wird geschlossen, mit Rueckgabedatum und Rueckgabe-Benutzer versehen und danach fuer die Bearbeitung gesperrt. Erst ab diesem Zeitpunkt fuehrt MET/TEAM ein belastbares Rekalibrierintervall, mit dem die Runtime arbeitet.

calServer kann diesen Zustand setzen, sehen und wieder zuruecknehmen.

Rueckgabe-Status einrichten¶

Ausgeloest wird die Rueckgabe ueber einen Kalibrierstatus. In Administration -> Statusverwaltung traegt genau ein Kalibrierstatus die Markierung METTEAM Rueckgabe.

calServer liefert dafuer den Status METTEAM Rueckgabe mit, deaktiviert. Das Aktivieren ist eine bewusste Entscheidung: ab da schliesst jeder Wechsel auf diesen Status das zugehoerige CallSheet in MET/TEAM.

Sie koennen auch einen eigenen Status markieren. Es darf immer nur einer aktiv sein; ein zweiter wird abgelehnt. Der Grund ist nicht Ordnungsliebe: beim Import muss eindeutig sein, welcher Status auf eine in MET/TEAM geschlossene Kalibrierung gesetzt wird.

Rueckgabe-Benutzer¶

MET/TEAM traegt zu jeder Rueckgabe ein, wer sie vorgenommen hat. Den Namen loest es ueber seine eigene Benutzerliste auf — nicht ueber SQL-Server-Logins.

Standardmaessig geht der Sync-Login als Rueckgebender durch. Das passt nur, wenn dieser Login in MET/TEAM auch als Anwender gefuehrt wird. In vielen Installationen ist er ein reiner Datenbank-Login, und dann bleibt der Rueckgebende drueben leer: die Rueckgabe laeuft, ist aber niemandem zurechenbar.

Deshalb gibt es unter Einstellungen das Feld Rueckgabe-Benutzer:

Leer heisst „nimm den Sync-Login" — das bisherige Verhalten.
Ausgefuellt heisst: dieser Name unterschreibt die Rueckgabe. Er muss auf einen Benutzernamen aus MET/TEAM passen, nicht auf einen SQL-Login. Die Verbindung selbst bleibt unveraendert.

Ob der Name drueben ankommt, sagt die Diagnose: passt er auf keinen MET/TEAM-Anwender, steht dort eine Warnung. Sie erscheint nur, wenn ein Rueckgabe-Status aktiv ist — wer die Rueckgabe nicht nutzt, braucht den Benutzer nicht.

Was beim Setzen passiert¶

calServer prueft, ob alle fuer die Rueckgabe noetigen Angaben vorliegen.
Der Statuswechsel wird gespeichert und die Rueckgabe eingereiht.
Der naechste Synchronisationslauf (alle 15 Sekunden) schliesst das CallSheet in MET/TEAM und gibt es zurueck.
Die Kalibrierung ist danach auch in calServer schreibgeschuetzt. Nur der Status bleibt aenderbar.

Der Schreibschutz ist kein Selbstzweck: das CallSheet ist in MET/TEAM gesperrt, jede weitere Aenderung in calServer kaeme dort nicht mehr an, und beide Systeme liefen auseinander.

Was beim Zuruecknehmen passiert¶

Waehlen Sie auf der Kalibrierung einen anderen Status. calServer oeffnet das CallSheet in MET/TEAM wieder (spl_CallSheets_REOPEN), der Schreibschutz faellt weg, und angestaute Aenderungen werden nachgereicht.

Aenderungen, die waehrend der Rueckgabe entstanden sind (etwa aus dem Import), gehen dabei nicht verloren: sie warten in der Warteschlange und laufen nach dem Wiedereroeffnen durch.

Oeffnet jemand das CallSheet in MET/TEAM selbst wieder, erkennt der naechste Importlauf das und hebt den Schreibschutz auf.

Wenn Werte fehlen¶

calServer unterscheidet zwei Faelle.

Der Statuswechsel wird abgewiesen, wenn die Rueckgabe technisch nicht stattfinden kann:

Fehlt	Warum
Scheinnummer	MET/TEAM findet das CallSheet ueber sie (`cCallSheetNumber`)
Verknuepftes Geraet	Ohne Geraet gibt es kein CallSheet
MET/TEAM-Synchronisation des Geraets	Auf der Geraeteseite unter MET/TEAM aktivieren
Uebertragung von Geraet oder Kalibrierung	Der naechste Synchronisationslauf legt sie an

Gewarnt wird, wenn sie stattfindet, aber unvollstaendig bleibt:

Fehlt	Folge
Naechstes Kalibrierdatum	Die Rueckgabe laeuft, MET/TEAM behaelt aber sein eigenes Rekalibrierintervall (`tMaintNextDate`) statt das aus calServer zu uebernehmen

Der Unterschied ist Absicht: es gibt Installationen, die das Rekalibrierintervall in MET/TEAM fuehren. Fuer die waere eine Sperre reine Behinderung. Die Warnung erscheint trotzdem an allen vier unten genannten Stellen, damit der Fall nicht unbemerkt bleibt.

Ohne konfigurierte MET/TEAM-Instanz greift keine dieser Pruefungen: der Status ist dann ein gewoehnlicher calServer-Status.

Wo die Meldung landet¶

Scheitert eine Rueckgabe erst beim Uebertragen (Verbindung, Ablehnung durch MET/TEAM), melden sich vier Stellen:

Auf der Kalibrierung ein Hinweis mit dem Zustand und dem Grund, samt Knopf Erneut versuchen.
In der Kalibrierungsliste die Spalte METTEAM Rueckgabe (ueber die Spaltenauswahl einblendbar, filterbar).
Im Protokoll unter Synchronisation -> Rueckgaben -> Im Protokoll anzeigen (Quelle push_calibration_close).
In der Glocke unter System, fuer alle mit dem Recht configure_METTEAM_synchronisation.

Die Kachelgruppe Rueckgaben im Reiter Synchronisation zeigt, wie viele CallSheets zurueckgegeben sind und wie viele haengen.

Wenn eine Rueckgabe lange steht¶

Solange ein CallSheet zurueckgegeben ist, nimmt MET/TEAM keine weiteren Aenderungen an. calServer stellt sie deshalb zurueck, statt sie zu verwerfen — sie laufen, sobald jemand einen anderen Status waehlt.

Zieht sich das ueber viele Laeufe hin (rund zwoelf Minuten), meldet sich calServer einmalig ueber Protokoll und Glocke. Der Eintrag bleibt dabei in der Warteschlange: die Meldung ruft jemanden, sie wirft nichts weg. Ist die Rueckgabe in Ihrem Betrieb fachlich tagelang normal, koennen Sie die Meldung ignorieren — es geht nichts verloren.

Protokoll¶

Der Reiter Protokoll fuehrt chronologisch, was bei der Synchronisation schiefging — Import wie Export, je Instanz.

Spalte	Inhalt
Zeitpunkt	Wann der Eintrag geschrieben wurde
Richtung	Import (MET/TEAM → calServer) oder Export
Entitaet	Geraet, Kalibrierung, Messwerte, Standort
Geraet	Geraetenummer des betroffenen Geraets
Datensatz	MET/TEAM-UID des betroffenen Datensatzes
Fehler	Die Meldung, an der es scheiterte

Die Spalte Geraet beantwortet die Frage, die auf jeden Importfehler folgt: welches Geraet steht still. Sie wird beim Protokollieren festgehalten, nicht beim Anzeigen ermittelt — ein spaeter geloeschtes Geraet bleibt damit benennbar, und ein Import, der den Datensatz gar nicht erst anlegen konnte, nennt es trotzdem.

Leer bleibt sie in drei Faellen: Der Eintrag betrifft kein Geraet (Verbindungsfehler, Pass-Abbruch), das Geraet ist calServer noch nie begegnet und die Quellzeile traegt seine Nummer nicht, oder der Eintrag betrifft eine Normal-Verknuepfung. Eintraege aus der Zeit vor dieser Spalte holen den Namen beim ersten Anzeigen nach, soweit die Zuordnung noch besteht.

Ueber Richtung und Quelle laesst sich die Liste eingrenzen; „Nur Konflikte" zeigt die Faelle, in denen ein Import eine noch nicht zugestellte lokale Aenderung ueberschrieben hat.

Kontroll-Dashboard (Widgets)¶

Wer die MET/TEAM-Seite sehen darf (Operation configure_METTEAM_synchronisation), findet im Widget-Katalog des Dashboards die Gruppe Schnittstellen mit zwei Kacheln. Ohne dieses Recht stehen sie nicht im Katalog — und eine bestehende Kachel zeigt dann nur noch den Hinweis, dass die Berechtigung fehlt.

Kachel	Zeigt	Vorgabegroesse
MET/TEAM-Uebersicht	Die vier Zaehler der Export-Warteschlange (Wartend, In Verarbeitung, Fehlgeschlagen, Erledigt), dazu die Warnungen „nicht erreichbar" und „Synchronisation abgeschaltet" sowie den Knopf Fehlgeschlagene erneut einreihen	volle Breite, flach
MET/TEAM-Protokoll	Die juengsten Protokoll-Eintraege mit Zeitpunkt, Richtung, Geraet und Fehler	volle Breite, hoch

Die Vorgabegroessen sind so gewaehlt, dass die Uebersicht ueber dem Protokoll steht, wenn beide nacheinander hinzugefuegt werden: erst die Zahl, die sagt dass etwas haengt, darunter die Zeilen, die sagen woran. Verschieben und Groesse aendern geht wie bei jeder anderen Kachel.

Im Zahnrad jeder Kachel stehen:

MET/TEAM-Instanz — welche Instanz die Kachel zeigt. Ohne Auswahl zeigt die Uebersicht die Primaer-Instanz und das Protokoll alle Instanzen. Zwei Kacheln mit verschiedenen Instanzen auf demselben Dashboard sind erlaubt und der uebliche Fall bei Multi-Instanz-Betrieb.
Richtung (nur Protokoll) — Import, Export oder beides.
Zeilen (nur Protokoll) — wie viele Eintraege die Kachel zeigt (1–50).
Titel — eigene Ueberschrift statt der Vorgabe.

Der Pfeil im Kachelkopf fuehrt auf diese Seite, und zwar auf den Reiter, der dasselbe in voller Breite zeigt: Synchronisation bei der Uebersicht, Protokoll beim Protokoll, jeweils auf der Instanz der Kachel (/admin/metteam?tab=log&instance=<uid>).

Die Kacheln sind bewusst lesend: Ausser dem erneuten Einreihen fehlgeschlagener Eintraege stellen sie nichts um. Konfiguration, Verbindungstests, Copy-All und das Leeren des Protokolls bleiben auf dieser Seite.

Nicht in der Dashboard-Freigabe

Ein oeffentlich geteiltes Dashboard zeigt beide Kacheln nur als Hinweis, dass sie dort nicht zur Verfuegung stehen. Der Schnappschuss der Freigabe traegt fuer sie keine Daten — Protokollzeilen enthalten Fehlermeldungen und Geraetenummern, und wer die sehen darf, entscheidet eine Berechtigung, die es ohne Anmeldung nicht gibt.

Werkzeuge¶

Der Reiter Werkzeuge auf der MET/TEAM-Seite buendelt die Diagnose- und Reparaturfunktionen. Alle Werkzeuge arbeiten auf der oben ausgewaehlten Instanz.

Diagnose¶

Ein Knopf, ein Bericht — rein lesend:

Abschnitt	Inhalt
Verbindung	Erreichbarkeit, SQL-Server-Version, MET/TEAM-Version aus der `Version`-Tabelle
Schnittstelle	Soll/Ist-Abgleich aller provisionierten Objekte gegen den Systemkatalog von MET/TEAM; fehlende Prozeduren und Trigger werden namentlich benannt
Warteschlange in MET/TEAM	`AuditLog2` je Tabelle und Operation mit aeltestem offenen Eintrag, dazu `AssetSync` und `Sync`
Export-Warteschlange	Zaehler je Status und letzter Protokollfehler auf calServer-Seite, dazu der Zustand des Push-Workers: Schalter, geplante Aufgabe, letzter Lauf

Oben stehen die Befunde im Klartext, schwerster zuerst.

Was die Diagnose findet, was der Status nicht sieht

Der Reiter Synchronisation kennt nur den Schnittstellen-Stempel — eine Notiz in calServer, kein Blick in MET/TEAM. Wird dort ein Trigger von Hand geloescht, aendert das die Notiz nicht: Der Reiter meldet weiterhin die installierte Version, die Synchronisation steht trotzdem. Die Diagnose sieht im Systemkatalog nach und benennt genau die fehlenden Objekte.

Findet sie welche, steht „Jetzt provisionieren" direkt neben dem Befund — auch dann, wenn der Stempel behauptet, alles sei installiert. Der Katalog schlaegt die Notiz.

Ein gruener Stempel ist kein Nachweis

Aus demselben Grund meldet der Reiter Synchronisation den Stempel blau und nicht gruen: Er sagt, worauf die Notiz steht, nicht was in MET/TEAM steht. Wer wissen will, ob die Schnittstelle wirklich vollstaendig ist, laesst die Diagnose laufen. Das ist der einzige Weg, der nachsieht.

Ein alter Zeitstempel unter „Aeltester" ist der direkte Beweis, dass der Import die Warteschlange nicht abarbeitet.

Wartende Eintraege, die niemand abholt

Stehen unter pending Eintraege, benennt die Diagnose auch, warum sie stehen. Zwischen dem Klick und MET/TEAM liegen drei Schalter hintereinander, und jeder von ihnen haelt die Warteschlange geraeuschlos an — nichts schlaegt fehl, es passiert nur nichts:

Befund	Was zu tun ist
Push-Worker ist ausgeschaltet	Reiter Synchronisation → „Ausgehender Push-Worker" einschalten und speichern
Geplante Aufgabe „MET/TEAM-Abgleich (ausgehend)" laeuft nicht mit	Server & Wartung → Betrieb → Aufgabe einschalten
Aufgabe eingeplant, aber seit ueber 15 Minuten (oder noch nie) gelaufen	Der Laravel-Scheduler laeuft nicht. Er wird mit `autostart=false` ausgeliefert — siehe Steuerungen

Ohne diese Aufschluesselung sehen alle drei Faelle gleich aus: eine Zahl, die sich nicht bewegt. Die Sync-Hoheit (sync_master) ist der vierte Schalter und hat einen eigenen Befund weiter oben.

Punktreparatur¶

Ein einzelnes Geraet oder eine einzelne Kalibrierung erneut in die Export-Warteschlange stellen — statt Copy-All ueber alle Datensaetze laufen zu lassen. Datensatztyp waehlen, Datensatz-ID aus calServer eintragen, einreihen.

Protokoll leeren¶

Im Reiter Protokoll loescht der Knopf „Protokoll leeren" alle Eintraege der gewaehlten Instanz. Andere Instanzen bleiben unberuehrt.

MET/TEAM-Tabellen leeren¶

Nicht umkehrbar

Dieses Werkzeug loescht Daten in der Datenbank des Kunden. Es ist fuer die Erstinitialisierung und fuer Testsysteme gedacht.

Nur fuer Superadmins sichtbar. Entweder eine einzelne Tabelle oder der feste Sync-Tabellensatz (Assets, CallSheets, Facilities, Types, Points, PointUncertainties, PointTolerances, PointReadings, PointStandardReadings).

Schranken:

Der Datenbankname muss zur Bestaetigung exakt eingetippt werden
Solange die Export-Warteschlange offene Eintraege hat, verweigert der Server das Leeren — sonst schreibt der Push-Worker sofort wieder in die geleerte Datenbank
Jede geleerte Tabelle landet mit Zeilenzahl im Systemprotokoll

Nach dem Leeren kennt MET/TEAM keine offenen Aenderungen mehr. Anschliessend ist ein Copy-All noetig.

Schnittstellen-Prozeduren im Datenbank-Manager¶

Unter Administration → Datenbank laesst sich die MET/TEAM-Verbindung auswaehlen. Neben Abfragen sind dort EXEC-Aufrufe der von calServer provisionierten Schnittstellen-Prozeduren moeglich — damit laesst sich nachstellen, was der Import sieht:

EXEC Get_List_Inventory_UPDATE @limit = 10
EXEC Get_Total_Calibration
EXEC Get_Inventory @nAssetUID = '…'

Freigegeben sind ausschliesslich die Get_*-Prozeduren und spl_CallSheetResults_COUNT. Die Set_CopiedToMySQL_For_*-Prozeduren veraendern die Sync-Markierungen und laufen nur im Schreibmodus. Alles andere, insbesondere die Schreibprozeduren von MET/TEAM selbst, bleibt gesperrt.

Fehlerbehebung¶

Problem	Loesung
Nichts synchronisiert, Ursache unklar	Zuerst Werkzeuge → Diagnose ausfuehren
Verbindungsfehler	Server-URL und Zugangsdaten pruefen
Feldzuordnung fehlgeschlagen	Feldtypen ueberpruefen
Duplikate nach Import	Eindeutige Schluesselfelder pruefen
Timeout	Batch-Groesse reduzieren
Einzelnes Geraet kommt nicht an	Werkzeuge → Punktreparatur
Geraete stehen unter `pending` und bewegen sich nicht	Werkzeuge → Diagnose — sie benennt den haltenden Schalter
Speichern schlaegt nur mit gefuelltem Passwortfeld fehl	Fehlender `APP_KEY`, siehe unten

Speichern geht nur mit leerem Passwortfeld¶

Symptom: Die Verbindungsdaten lassen sich speichern, solange das Passwortfeld leer bleibt. Sobald ein Passwort darin steht, antwortet die Oberflaeche mit einem Fehler — und Verbindung testen meldet trotzdem gruen.

Ursache: Der Anwendungsschluessel APP_KEY der API fehlt oder passt nicht. calServer legt Passwoerter ausschliesslich verschluesselt ab; ohne brauchbaren Schluessel gibt es nichts, womit es das Passwort ablegen koennte, und im Klartext legt es keines ab. Alles andere an der Seite funktioniert weiter, weil nur dieses eine Feld verschluesselt wird — deshalb sieht es nach einem MET/TEAM-Problem aus, obwohl keins vorliegt. Der gruene Verbindungstest gehoert zum selben Bild: Er laeuft mit dem noch aus V1 geerbten Klartextpasswort, das V2 nur liest und nie ueberschreibt.

Bestaetigen: Werkzeuge → Diagnose ausfuehren. Fehlt der Schluessel, steht der Befund ganz oben in der Liste und nennt APP_KEY beim Namen.

Beheben:

# Einen Schluessel erzeugen (gibt ihn nur aus, schreibt nichts)
docker exec calserver-api-v2 php artisan key:generate --show

Den Wert als LARAVEL_APP_KEY in die .env der Installation eintragen und die API neu starten. Danach laesst sich das Passwort speichern.

Einen vorhandenen APP_KEY nie ersetzen

Der Schluessel entschluesselt alles, was calServer verschluesselt abgelegt hat — Lizenzschluessel, KI-Zugangsdaten, Backup-Ziele. Wird er getauscht, sind diese Werte nicht mehr lesbar und muessen neu eingegeben werden. Ein neuer Schluessel gehoert nur dorthin, wo bisher gar keiner stand.

MSSQL-Verbindungsdiagnose¶

Bei Verbindungsproblemen nach Infrastruktur-Upgrades (Server-Umzug, Container-Rebuild, OS-Update) steht ein dedizierter Console-Command zur Verfuegung. In V2:

docker exec calserver-api-v2 php artisan metteam:test-connection

Details und alle Optionen: Artisan Commands.

Das V1-Pendant fuer Installationen, die noch auf Yii laufen:

cd httpdocs/protected
php yiic testmssqlconnection run

Der Command prueft automatisch:

Schritt	Pruefung
PHP-Extensions	Ist `pdo_sqlsrv` geladen? Welche Version? Verfuegbare PDO-Treiber
ODBC-Treiber	Installierte Treiber aus `/etc/odbcinst.ini`
Credentials	Gespeicherte Verbindungsdaten anzeigen (Passwort maskiert)
Netzwerk	TCP-Erreichbarkeit des Servers via `fsockopen`
PDO-Verbindung	Direkter Verbindungstest mit detaillierter Fehlermeldung
TLS-Varianten	Bei Auth-Fehler: automatischer Test mit `TrustServerCertificate=1` und `Encrypt=0`

Credentials ueberschreiben:

# Alternatives Passwort testen
php yiic testmssqlconnection run --password=AnderesPasswort

# Komplette Verbindungsdaten ueberschreiben
php yiic testmssqlconnection run --server=10.0.0.1 --port=1433 --username=user --password=pass --database=db

Parameter	Beschreibung
`--server`	Server-IP oder Hostname ueberschreiben
`--port`	Port ueberschreiben (Standard: 1433)
`--username`	Benutzername ueberschreiben
`--password`	Passwort ueberschreiben
`--database`	Datenbankname ueberschreiben

Haeufigste Ursache nach Infrastruktur-Upgrade

ODBC Driver 18 erzwingt TLS-Verschluesselung per Default (anders als Driver 17). Wenn der TLS-Variantentest mit Encrypt=0 oder TrustServerCertificate=1 erfolgreich ist, muss entweder ein gueltiges Zertifikat auf dem SQL Server konfiguriert oder die DSN-Option in der sqlSrvDb()-Funktion angepasst werden.