Zum Hauptinhalt springen

Blueprints konfigurieren

Bitte Konnie, sinnvolle Optionen einer eigenen Ansicht als Einstellungen bereitzustellen. Zum Beispiel: „Erstelle eine Maschinenansicht mit einstellbarer Überschrift, Filterhöhe und Statusanzeige. Verwende deutsche und englische Beschriftungen.“ Konnie erzeugt die Ansicht, ihre Eingabeelemente und passende Standardwerte zusammen.

Wähle den Blueprint im App-Editor und öffne Konfiguration. Passe unter Blueprint-Einstellungen die gewünschten Werte an. Die Vorschau aktualisiert sich, und die normale Entwurfsspeicherung übernimmt die Werte. Verschiedene Platzierungen haben eigene Werte, auch wenn Code und Standardwerte gleich sind.

Text-, Zahlen-, Checkbox-, Schalter-, Dropdown-, Radio- und Mehrfachauswahlfelder werden unterstützt. Einstellungen können gruppiert sein. Konnie wählt passende Eingabeelemente und gibt jeder Einstellung einen gültigen Standardwert. Ein Blueprint ohne erzeugte Einstellungen funktioniert weiterhin wie zuvor.

Standardwert bedeutet, dass diese Platzierung keinen eigenen Wert hat. Eigener Wert bedeutet, dass sie einen Standardwert überschreibt. Mit Zurücksetzen neben einer Einstellung stellst du ihren Standardwert wieder her. Alle Einstellungen zurücksetzen stellt sämtliche Standardwerte wieder her. Dabei wird der Blueprint-Code nicht umgeschrieben.

Bei einer ungültigen Eingabe erklärt eine Meldung das Problem. Die gespeicherte Einstellung bleibt unverändert. Korrigiere den Wert oder verwirf die unfertige Eingabe mit Escape. Reine Codeänderungen erhalten eigene Werte. Eine geänderte Definition muss zu diesen Werten passen; unvereinbare Änderungen werden abgelehnt.

Prüfe und veröffentliche die App über den normalen Ablauf. Veröffentlichte Versionen halten Code, Einstellungsdefinition und Werte der Platzierungen zusammen fest. Änderungen am nächsten Entwurf verändern die aktuell veröffentlichte App nicht.

Einstellungsdefinition bearbeiten öffnet einen erweiterten JSON-Editor. Normalerweise erstellt Konnie diese Definition. Für alltägliche Anpassungen musst du weder Code noch JSON bearbeiten.

Wenn eine technische Prüfung nicht fertig wird​

Konnie prüft erzeugten Code vor dem Speichern. Bei einem Compiler-Zeitlimit wiederholt sie die Prüfung derselben vorgeschlagenen Änderung automatisch einmal. Ein vorübergehender Compiler-Ausfall lässt den zuletzt gespeicherten Entwurf unverändert und wird getrennt von einem Codefehler angezeigt. Scheitert auch die Wiederherstellung, bleibt der Änderungsvorschlag im Chat erhalten und Konnie erklärt, dass er noch nicht gespeichert wurde. Auch nach erfolgreicher Prüfung und Speicherung müssen die tatsächliche Vorschau und ihre Bedienung geprüft werden.

Datensätze und Workflows verbinden​

Ein Blueprint kann eine vollständige Arbeitsoberfläche für dauerhaft gespeicherte App-Daten sein: ein Anfrageformular neben einer Warteschlange, ein ausgewählter Datensatz mit Bearbeitungsfunktionen oder ein Diagramm mit Workflow-Buttons. Zum Zugriff auf verbundene Datensätze benötigt er keine sichtbare Tabellenkomponente.

Bitte Konnie, das echte Tabellenschema und die Automatisierung im ausgewählten Werk und System zu ermitteln und beide mit der App zu verbinden. Zum Beispiel: „Erstelle einen Anfragearbeitsplatz mit unserer Tabelle Anfragen. Zeige offene Anfragen als Karten, lass Benutzer eigene Anfragen erstellen und bearbeiten und starte den aktiven Workflow Anfrage prüfen über einen separaten Button für den ausgewählten Datensatz. Behalte Eingaben bei Fehlern und zeige den Workflow-Fortschritt. Verwende deutsche und englische Texte.“ Verwende Namen aus deinem Arbeitsbereich; Konnie muss vor der Erstellung die echten IDs und Spaltenschlüssel ermitteln.

Die Verbindungen unter Daten erlauben die benötigten Lese-, Erstellungs-, Änderungs- und Löschvorgänge und bestimmen den Zugriff auf eigene Datensätze. Die Verbindungen unter Automatisierungen legen stabile Workflow-Aktions-IDs fest. Der Blueprint verwendet ennea.dataSources und ennea.automations mit diesen logischen IDs; die Plattform löst Tabelle und Workflow aus der App-Konfiguration auf. Einen Workflow zu verbinden oder einen Datensatz zu lesen startet ihn nicht. Die SDK-Verträge und das Verhalten bei Wiederholungen beschreiben App-Datenquellen und Automatisierungen in Apps.

Konnies JSX-Editor erhält die aktuellen benannten Verbindungen, berechtigte Tabellenschemas und tatsächliche Workflow-Eingabepfade. Diese Verbindungsdaten enthalten keine Datensatzwerte, Tabellenstandards oder konfigurierten Workflow-Festwerte. Eingabepfade zeigen Workflow-Verweise; sie definieren keine Pflichtfelder oder Typen. Bei nicht verfügbarem oder ausgelassenem Kontext muss Konnie die fehlende Einrichtung erklären, statt ein Schema oder eine Eingabezuordnung zu erraten. Bei vielen Verbindungen können Details ausgelassen werden, damit der Kontext für die Erstellung begrenzt bleibt.

Einen Datensatz anzulegen und einen Workflow zu starten sind getrennte Vorgänge. Zeige ihre Ergebnisse getrennt. Wurde der Datensatz gespeichert und ist die Workflow-Antwort unklar, behalte den gespeicherten Datensatz und wiederhole nur diesen Workflow mit seinem ursprünglichen Aufrufschlüssel und unveränderten Eingaben. Erstelle keinen weiteren Datensatz und keine neue Workflow-Absicht, um ein Teilergebnis zu verdecken. Eine erhaltene Ausführung kann noch laufen, warten oder eine Freigabe benötigen; zeige den Abschluss erst, wenn der Ausführungsbeleg ihn bestätigt.

Prüfe den erzeugten Entwurf, seine Verbindungen und angeforderten Fähigkeiten vor der Veröffentlichung. Teste Datensatzzugriff und Änderungen mit vereinbarten Testdaten; verbundene Automatisierungen werden nur aus einer veröffentlichten App ausgeführt. Prüfe die veröffentlichte Oberfläche als vorgesehener Benutzer, einschließlich fehlendem Zugriff, Doppelklicks, parallelen Änderungen, verlorener Antwort und erneutem Laden. Entwurfserstellung, Bereitstellung zur Prüfung und Kompilierung belegen weder Veröffentlichung noch einen erfolgreichen operativen Vorgang.

Kundenaufträge und Positionsrückmeldungen​

Ein Arbeitsplatz-Blueprint liest native Kundenauftragsbeziehungen mit data.query('customerOrders', {workCenterId, scope: 'planned', skip: 0, limit: 25}) oder ennea.customerOrders.list(...). Prüfe ok und verwende anschließend data.customerOrders, totalCount und hasMore; erhöhe skip für jede Seite um das zurückgegebene limit. Höchstens 50 Kundenaufträge werden pro Seite gelesen. Dafür sind Kundenauftrags- und Produktionsauftrags-Leserechte im ausgewählten Werk und System erforderlich.

Jeder Auftragskopf enthält stabile lines; jede Position enthält ihre verknüpften Haupt-Produktionsaufträge unter productionOrders, einschließlich aller Arbeitsgänge und Ausführungssplits. Halte Positionen und ihre Einheiten getrennt. Komponentenunteraufträge erfüllen keine weitere Kundenposition. data.get('customerOrders', idOrOrderNumber) liefert data.customerOrder. Produktionsauftragsdetails enthalten vollständige steps und splits mit quantityProduced; Listen erhalten diese Ausführungsdetails mit includeExecution: true; bei unbekannter produzierter Menge ist die Restmenge remainingQuantity eines Splits null. Zu große Ausführungsgraphen schlagen explizit fehl, statt unvollständigen Fortschritt zurückzugeben. Splitlisten unterstützen productionOrderId/productionOrderIds, scope: 'all', skip, limit und hasMore. ennea.splits.get(splitId) liest immer genau diesen Split.

Konfiguriere für jede aufklappbare Position einen nativen eingebetteten ProductionProgressReport-Adapter und zeige ihn so an:

<ProductionProgressReport
  id="position-report"
  orderContext={{
    order: { _id: order._id },
    splitContext: { splitId: split._id },
  }}
/>

Das Bedienelement liest Auftrag und Split erneut mit den geltenden Rechten, prüft ihre Verknüpfung und den gebundenen Arbeitsplatz und aktiviert dann den normalen Rückmeldeablauf. Der gemeinsame aktive Auftrag der App wird nicht umgeschaltet. Ein ausdrücklicher orderContext ohne splitContext bedeutet Auftragsrückmeldung; der gemeinsam aktive Split wird dabei nicht übernommen. Ohne orderContext gilt das bisherige Verhalten für den aktiven Auftrag. Das Lesen oder Aufklappen einer Position bucht keinen Fortschritt. Prüfe Rückmeldungen mit vereinbarten lokalen Testdatensätzen; Speichern oder Kompilieren der App belegt noch kein operatives Ergebnis.

Für einen eigenen Button, der die gesamte Restarbeit eines Splits abschließt, nutze die bestehende Aktion mit der ausdrücklichen atomaren Abschlussoption:

const result = await ennea.splits.updateProgress(splitId, {
  completeToPlanned: true,
  expectedQuantity: displayedSplit.quantity,
});

Rufe sie nur nach einem Bedienerklick auf einer Bereitstellung auf, die diese Option unterstützt. expectedQuantity muss der angezeigten gültigen positiven Planmenge genau dieses Splits entsprechen. Der Wert ist eine Vorbedingung, keine zu schreibende Menge. Lasse quantityProduced und status weg. Der Server liest die aktuellen gespeicherten Werte atomar, behält die größere Menge aus Ist und Plan und setzt den Split auf completed. So bleibt 3 / 1 erhalten; 2 / 2 mit dem Status queued wird abgeschlossen. Ein bereits vollständig abgeschlossener Split liefert unchanged: true ohne erneutes Speichern oder Ereignis. Unbekannte Mengen sind nicht null: Fehlt eine gültige Plan- oder Istmenge, schlägt die Aktion mit invalid_completion_quantity fehl. Ein ungültiges expectedQuantity wird mit invalid_expected_quantity abgelehnt; eine geänderte gespeicherte Planmenge mit 409 split_quantity_changed, jeweils vor einer Schreiboperation. Aktualisiere dann die geänderte Planung und lasse den Bediener erneut bestätigen; übernimm eine neue Planmenge nicht stillschweigend.

Die normale Option quantityProduced setzt eine absolute kumulierte Menge; sie addiert keine Differenz. Bilde den Abschluss nicht durch Lesen einer Menge in der App und anschließendes Zurückschreiben nach: Dazwischen kann eine weitere Rückmeldung eintreffen. Prüfe result.ok sowie Status und Menge des genauen Splits in result.data.split und aktualisiere anschließend den Erfüllungsgraphen. Leseantworten enthalten data.split (data.item ist ein Alias), Aktualisierungen data.split, data.step und data.order. Kläre einen Timeout vor einem erneuten Versuch durch erneutes Lesen mit den geltenden Rechten; zeige keinen Erfolg allein aufgrund der angezeigten Menge an. Die bisherigen Prüfungen für veröffentlichte App-Fähigkeit, zugewiesenen und gebundenen Arbeitsplatz sowie Rückmeldevoraussetzungen gelten weiter; die Option benötigt keine zusätzlichen Berechtigungsfreigaben.