Code ist unser letztes Werkzeug
Die meisten Anforderungen lassen sich mit dem Standardmodell abdecken: Soft Types, Attribute, Object Initialization Rules, Lebenszyklen und Workflow-Vorlagen. Diesen Weg prüfen wir immer zuerst, denn jede Zeile eigener Code muss jemand durch das nächste Upgrade tragen.
Ist Code die richtige Antwort, entsteht ein kleines, fokussiertes Modul mit genau einer Aufgabe, einem benannten Verantwortlichen und einer dokumentierten Begründung direkt daneben.
Wie ein Customizing entsteht
- In Git, in einem Repository, das Ihnen gehört, und jede Änderung wird von einem zweiten Engineer geprüft.
- Durch eine Pipeline, nie auf einem Server kompiliert oder von Hand hineinkopiert.
- Mit Tests, die gegen eine kurzlebige Windchill-Instanz laufen, bevor irgendetwas weitergereicht wird.
- In ein Inventar, das festhält, was es tut, welche PTC-APIs es berührt und wer es pflegt.
Typische Aufgaben
- Nummerierungs- und Benennungsregeln, die über Initialisierungsregeln hinausgehen
- Workflows für das Änderungswesen mit parallelen Prüfungen, Vertretung und Eskalations-Timern
- Freigabeprüfungen, die eine Stückliste validieren, bevor sie in den nächsten Status wechseln kann
- Berichte und Dashboards auf Basis von Windchill-Daten
- Administrator-Tools: Bulk-Loader, Massenänderungen und Bereinigungsjobs
Upgrade-sicher by Design
Wir bauen auf unterstützten APIs und Erweiterungspunkten auf, ändern nie PTCs eigene Dateien und erfassen jedes Override im Inventar. Kommt das nächste Release, ist das Upgrade des Customizings ein Rebuild mit Testlauf, keine Spurensuche.