Ticket rein. Geprüfte App raus.

Ausgangslage

Ein Satz beschreibt die Anpassung. Bis sie live ist, braucht es viele Handgriffe.

Ablauf

In fünf Schritten vom Wunsch zur installierten App

1. 1

   Beschreiben

   Sie schreiben oder diktieren in eigenen Worten, was Business Central können soll, mit Akzeptanzkriterien und auf Wunsch mit Anlagen, oder Sie laden ein ganzes Lastenheft oder den C/AL-Export Ihrer NAV-Anpassungen hoch, und die KI macht daraus die Tickets. Zu jedem Ticket schlägt sie ein Konzept vor oder überarbeitet Ihres, und Sie geben es frei.

   NeuKonzept freigegeben
2. 2

   Umsetzen

   Die KI liest Konzept, Anlagen, die Vorgaben der App und den vorhandenen Code, holt freie Objekt-IDs, Feldnummern und Enum-Werte von der Plattform und kompiliert mit den Code Cops und Regeln der App, bis der Build sauber ist. Danach prüft ein zweiter KI-Lauf die Umsetzung. Alles im eigenen Branch des Tickets.

   In Umsetzung
3. 3

   Prüfen

   Sie sehen alle Änderungen als Diff gegenüber dem Live-Stand, dazu die Compiler-Meldungen, die Funde des KI-Reviews und das Ergebnis der Schemaprüfung. Sie geben frei, schicken das Ticket mit „Nacharbeit durch KI“ zurück an die KI oder ändern den Code mit „Manuelle Nacharbeit“ selbst, im Browser oder in VS Code.

   Code Review
4. 4

   Testen

   Mit der Freigabe baut die Plattform eine neue Version und installiert sie in allen Umgebungen der Stufe Test, sofort oder zum nächsten festen Termin. Mit einem Testbenutzer öffnet sie danach die geänderten Seiten im Web-Client. Der Anforderer bekommt eine Test-Mail und nimmt über ihren Link ab oder meldet einen Fehler, ohne Konto auf der Plattform; abnehmen können auch Sie.

   Im TestAbgenommen
5. 5

   Live bringen

   Nur abgenommene Tickets kommen in den Live-Stand. Die Plattform baut neu und installiert in allen Live-Umgebungen, sofort oder gesammelt zum festen Termin, etwa jeden Abend um 18 Uhr. Die Projektbeteiligten bekommen eine technische Mail mit dem Ticket-PDF, Ihre Anwender auf Wunsch Versionshinweise, und die KI schreibt das Anwenderhandbuch fort. Auf Wunsch werden Fehler, die Anwender in Live sehen, zu Ticketvorschlägen.

   Im Live

Einblicke

So sieht ALForge aus

Bildschirmfotos aus der Plattform, aufgebaut wie Business Central, mit erfundenen Beispieldaten.

Für wen

Für BC-Partner und für Unternehmen mit eigenem Business Central

Sicherheit und Betrieb

Ihre Umgebungen bleiben unter Ihrer Kontrolle

Neu und geplant

Was neu ist und was als Nächstes kommt

Fragen

Häufige Fragen

Was müssen wir in Entra ID und Business Central einrichten?

Eine App-Registrierung mit den Business-Central-Berechtigungen AdminCenter.ReadWrite.All, API.ReadWrite.All und Automation.ReadWrite.All samt Administratorzustimmung. Die App autorisieren Sie im Admin Center und tragen sie in jeder Umgebung unter „Microsoft Entra-Anwendungen“ ein; die Schritte stehen auch im Formular beim Anlegen des Tenants. Mit der Microsoft-Graph-Berechtigung Application.Read.All liest die Plattform das Ablaufdatum des Client-Secrets selbst, sonst tragen Sie es ein. Vor dem Ablauf erinnert die Plattform Ihre Administratoren per Mail; fehlt das Datum, weist das Dashboard sie darauf hin. Für Mails kommt Mail.Send hinzu, für das Postfach des Posteingangs Mail.Read, in derselben oder einer eigenen App-Registrierung; beides lässt sich in Exchange Online auf die genutzten Postfächer beschränken. Für den Web-Client-Test legen Sie einen Testbenutzer mit Business-Central-Lizenz und Zugriff auf die Testumgebung an, mit den Rechten eines Anwenders (D365 BUS FULL ACCESS) und ohne SUPER. Für die Prüfung auf Fehler und lange SQL-Abfragen trägt die Plattform auf Wunsch die Application-Insights-Ressource Ihres Arbeitsbereichs im Admin Center einer Umgebung ein; die App-Registrierung für Business Central braucht dafür keine weitere Berechtigung. Die Umgebung schickt dann ihre ganze Telemetrie dorthin, und Business Central startet die Umgebung dafür sofort neu: Angemeldete Anwender werden abgemeldet, und laufende Vorgänge und Aufgaben der Auftragswarteschlange brechen ab. Ohne diesen Eintrag sieht die Prüfung online nur Apps mit eingeschalteten Telemetriedaten. Ist schon eine andere Ressource eingetragen, ersetzt die Plattform sie nicht; dann sieht die Prüfung ebenfalls nur diese Apps.

Funktioniert das mit Business Central On-Premise?

Ja. Auf Ihrem Business-Central-Server läuft dann der Connector, ein Windows-Dienst, der nur ausgehende HTTPS-Verbindungen zur Plattform aufbaut. Einen offenen Port, ein VPN oder eine Firewall-Regel für eingehende Verbindungen braucht es nicht, und welche Serverinstanzen die Plattform nutzt, legen Sie im Setup auf dem Server fest. Gebaut wird mit dem hinterlegten AL-Compiler, der zu Ihrer BC-Version passt. Ab Version 1.2.0 aktualisiert sich der Connector selbst, wenn gerade nichts läuft, nur von der gekoppelten Plattform und mit geprüfter Prüfsumme; startet die neue Version nicht, kommt die alte zurück, und abschalten lässt sich das jederzeit, auch auf dem Server. Ab Version 1.4.0 liest er für die Prüfung auf Fehler und lange SQL-Abfragen die Einträge der freigegebenen Instanzen in der Ereignisanzeige, ohne etwas zu ändern. Ab derselben Version misst er jede Minute CPU und Arbeitsspeicher; aufgezeichnet wird das je nach Wahl eines Administrators einen bis drei Tage lang oder dauerhaft, und die Werte bleiben 7 Tage. Während der Aufzeichnung warnt die Plattform in der Karte „Auslastung“ auf der Seite des Servers bei hoher Last oder knappem Speicher. Ab Version 1.5.0 misst der Connector nur noch während einer Aufzeichnung, und „Jetzt messen“ misst auch ohne Aufzeichnung sofort. Ab Version 1.6.0 meldet er auch die nur veröffentlichten Apps, und ab Version 1.6.1 deinstalliert er Apps oder hebt ihre Veröffentlichung auf, sobald Sie das in der Liste der installierten Apps auslösen. Objekt-IDs vergibt die Plattform nur, wo Ihre Lizenz sie erlaubt; die liest der Connector ab Version 1.1.0. Kennt die Plattform die Lizenz nicht, etwa bei einem älteren Connector, sagt das Job-Log, dass die IDs nicht gegen die Lizenz geprüft sind. Ist der Connector eines Servers länger als 5 Minuten ohne Kontakt, stehen seine Umgebungen im Dashboard unter „Umgebungen mit Problem“; einmal je Server steht dabei, was zu tun ist: für Administratoren mit einem Link zum Server, für alle anderen mit den Namen der Administratoren, die helfen können. Für die Telemetriedaten nimmt der Connector ab Version 1.3.0 die Telemetrie auf dem Server entgegen und gibt davon nur Fehlermeldungen und langsame Methoden über seine Verbindung weiter, ohne dass der Server Azure erreichen muss. Mit einem älteren Connector bekommt die Plattform von diesem Server keine Telemetrie. Den Web-Client-Test und die App ALForge gibt es nur online.

Über welchen Zugang arbeitet die KI, und was sieht sie?

Über Ihren eigenen KI-Zugang: direkt beim KI-Anbieter oder über Microsoft Foundry, Amazon Bedrock oder Google Vertex AI. Auf jedem dieser Wege arbeitet dieselbe KI. Welches ihrer Modelle sie nutzt, legen Sie für den Arbeitsbereich, je App und je Ticket fest. Die KI bekommt Ticket, Konzept, Anlagen, Ihre Rückmeldungen und die Vorgaben der App und liest den Quellcode der App, bei einem fehlenden Feld oder Objekt auch die anderen installierten Apps der Umgebung, als Quellcode, wo das Paket ihn enthält oder die App auf der Plattform liegt, sonst ihre Symbole. Dazu kommen die Dokumente, aus denen Sie Tickets erstellen lassen, die Mails im Posteingang mit ihren Word- und PDF-Anhängen und Bildern, Antworten auf Rückfragen und Test-Mails, Ihre Fragen zur App, die Fragen Ihrer Anwender per Mail, jeder Fund aus der Prüfung auf Fehler und lange SQL-Abfragen, den Sie von der KI erklären lassen, samt BC-Version und installierten Apps der Umgebung, On-Premise mit dem ganzen Text des Eintrags aus der Ereignisanzeige, und der C/AL-Export der NAV-Übernahme. Alles geht an den Anbieter Ihres Zugangs, der auch abrechnet; in einer EU-Region verarbeiten heute nur Amazon Bedrock und Google Vertex AI. Diktieren Sie, wandelt Ihr Browser die Sprache um, Edge über den Sprachdienst von Microsoft, Chrome über den von Google; die Plattform bekommt nur den Text.

Was kostet die KI je Ticket?

Das sehen Administratoren je Ticket, App, Arbeitsbereich und KI-Zugang, mit Tokens und geschätzten Kosten in US-Dollar. Je Ticket steht es in der Arbeitsbereich-Administration unter „KI-Nutzung“, je App auf einer eigenen Seite, das teuerste Ticket zuerst, und im Ticket-PDF, das ein Administrator herunterlädt, mit einer Zeile je Lauf. Geschätzt, weil die Plattform mit den Listenpreisen des KI-Anbieters rechnet; abgerechnet wird über den Anbieter Ihres Zugangs. Was die KI in einer Umsetzung schon gelesen hat, liest sie bei jedem weiteren Schritt aus dem Prompt-Cache des KI-Anbieters, zu einem Bruchteil des Eingabepreises; die KI-Nutzung zeigt diese Tokens unter „Cache gelesen“.

Können wir ein ganzes Lastenheft einspielen?

Ja, als Word oder PDF, dazu Mails oder eingefügten Text. Die KI schlägt je Anforderung ein Ticket vor, mit Akzeptanzkriterien, Priorität, App und der Stelle im Dokument, etwa Abschnitt 3.2. Was dieselben Objekte ändert, fasst sie zusammen, und sie vermerkt, was aufeinander aufbaut. Sie prüfen die Vorschläge, legen die Tickets mit einem Klick an und starten auf Wunsch die Umsetzung aller, jedes in seinem eigenen Branch; ein Ticket, das auf einem anderen aufbaut, wartet, bis jenes live ist.

Können Anforderungen auch per Mail kommen?

Ja. Die Plattform liest ein Postfach in Exchange Online, etwa tickets@firma.de, oder Sie ziehen Mails aus Outlook in den Posteingang. Die KI ordnet die Mails einem offenen Ticket zu oder schlägt neue vor, auch aus Word- und PDF-Anhängen und Bildern, etwa einem Screenshot im Mailtext, die dann als Anlage ans Ticket kommen. Ohne Ihren Klick entsteht kein Ticket, außer Sie schalten für die App den Autopiloten ein. Rückfragen zum Konzept gehen per Mail an den Absender, und seine Antwort landet von selbst am Ticket. Ebenso nimmt der Absender den Test über die Test-Mail ab. Als Schutz vor einer Flut von Mails ordnet die KI aus dem Postfach je Tag von selbst höchstens 25 Mails desselben Absenders und 200 je Arbeitsbereich ein; was darüber liegt, bleibt ohne KI offen im Posteingang, bis ein Mitglied es einordnen lässt oder selbst entscheidet, und der Autopilot übernimmt es auch dann nicht. Antwortet der Anforderer im selben Mailverlauf auf Rückfragen, auf die Test-Mail oder auf die Antwort zu seiner Frage, gilt für seine Antwort keine dieser Grenzen, und sie kommt vor den anderen Mails dran, damit etwa eine Abnahme nicht hinter einer Flut wartet.

Geht das auch ganz ohne Klick?

Ja, mit dem Autopiloten, den Administratoren je App einschalten. Kommt eine einzelne Anforderung von einem freigegebenen Absender ins Postfach, besteht die Mail die DMARC-Prüfung seiner Domain und ordnet die KI sie sicher einer App zu, legt er das Ticket an, klärt offene Fragen per Mail, setzt um und bringt es nach Test. Statt der DMARC-Prüfung genügt es auch, wenn die Mail angemeldet aus dem Microsoft-365-Mandanten des Postfachs kommt, da Exchange Online zwischen Adressen eines Mandanten, etwa zwei Domains Ihrer Firma, kein DMARC prüft; eine weitergeleitete Mail zählt dafür nicht. Sicher ist die Zuordnung auch, wenn der Betreff die App oder einen Kunden mit nur dieser App nennt und die KI dieselbe App wählt. Ist der Web-Client-Test bestanden, bekommt der Anforderer die Test-Mail, und nach seiner Abnahme plant der Autopilot Live ein; „In das Livesystem updaten“ führt er nie selbst aus. Ohne Web-Client-Test, also On-Premise oder ohne Testbenutzer, hält er nach Test an, ebenso bei Fehlern im Build, schweren oder mittleren Funden im KI-Review, am Kostenlimit je Ticket und nach dem Abbruch eines Jobs des Tickets, und ein Schalter hält ihn für alle Apps an. Auch eine einzelne Anforderung, die ein aktives Mitglied Ihres Arbeitsbereichs hochlädt, übernimmt er so; statt der Absenderprüfung zählt dann das Hochladen. Eine Mail, die in den Posteingang gezogen wird, muss dafür von einem freigegebenen Absender kommen. Ein Dokument, auch eine über „Tickets mit KI erstellen“ hochgeladene Mail, hat keinen Anforderer: Bei offenen Fragen im Konzept und vor der Abnahme hält er an, bis ein Mitglied das im Ticket klärt.

Wir arbeiten noch mit Dynamics NAV. Können Sie unsere Anpassungen übernehmen?

Ja, den Code. Sie laden den C/AL-Textexport der geänderten Objekte hoch, auf Wunsch dazu den unveränderten Standard-Export derselben Version für einen genauen Vergleich. Die Plattform findet die Anpassungen, auch direkt im Standardcode, und die KI fasst sie zu fachlichen Vorschlägen zusammen, mit einem Hinweis, wo Business Central das vielleicht schon im Standard kann. Mit „Alles übernehmen“ baut die KI dann alle Vorschläge, die Sie nicht beiseitelegen, als Erweiterung in die App: erst Tabellen und Felder, dann Seiten und Berichte, dann Code, jede Einheit als eigenen Commit, den der AL-Compiler geprüft hat. Was sie nicht eindeutig umsetzen kann oder was nicht kompiliert, wird ein Ticket mit Grund und C/AL-Auszügen, und das Übernommene geht wie jedes Ticket über KI-Review, Test und Abnahme nach Live. Einzelne Anpassungen übernehmen Sie stattdessen je als eigenes Ticket. Daten wie Debitoren, Artikel und Posten überträgt die NAV-Übernahme nicht.

Können Sie Erweiterungen weiterentwickeln, die wir schon im Einsatz haben?

Ja. Unter „Neue App“ wählen Sie eine Umgebung und eine dort installierte App, und die Plattform lädt deren App-Datei selbst herunter, online wie On-Premise; Apps von Microsoft blendet die Auswahl aus. Oder Sie laden den Quellcode als .zip oder die .app hoch. Steckt der Quellcode in der App-Datei, entwickeln Sie die App selbst weiter, und was das Paket an Berichtslayouts und Übersetzungen enthält, übernimmt die Plattform mit. Auf Wunsch prüft der App-Check die App gleich nach dem Anlegen auf Risiken, veralteten Code, Performance, fehlende Berechtigungen und Übersetzungen, je Befund mit einem Ticketvorschlag; sonst starten Sie ihn später im Reiter „App-Check“. Gibt der Herausgeber den Quellcode nicht im Paket frei, erweitern Sie seine App mit einer neuen App, die von ihr abhängt.

Pflegt die Plattform auch die Übersetzungen?

Auf Wunsch, je App. Die Texte im Code bleiben wie in AL üblich Englisch. Setzt die KI ein Ticket um, übersetzt sie die neuen und geänderten Texte gleich in jede Sprache der App, nach Ihren eigenen Änderungen auf Knopfdruck. Sie nimmt die Begriffe, die Business Central in der jeweiligen Sprache verwendet, im Deutschen etwa Debitor und Beleg. Fehlende und veraltete Übersetzungen stehen als Warnung bei den Compiler-Meldungen, und ändern zwei Tickets dieselbe Sprachdatei, führt die Plattform das beim Merge selbst zusammen.

Wie wird die Qualität geprüft?

Jede Umsetzung wird mit dem AL-Compiler und den Code Cops gebaut, die Sie je App einstellen, in der Vorgabe CodeCop und PerTenantExtensionCop; installiert wird nur ein fehlerfreier Build. Ein zweiter KI-Lauf prüft jede KI-Umsetzung gegen Konzept und Vorgaben und sucht Logik-, Performance- und Sicherheitsprobleme. Vor jedem Einspielen prüft AppSourceCop, ob Business Central das neue Datenschema annimmt. Nach der Installation in Test öffnet die Plattform mit einem Testbenutzer die geänderten Seiten im Web-Client und hält sie in Screenshots fest. Fachlich testet der Anforderer in der Testumgebung und nimmt über die Test-Mail ab; abnehmen können auch Sie. Nach Live meldet auf Wunsch die Telemetrie, welche Fehler Ihre Anwender sehen.

Bekommen unsere Anwender die Rechte auf neue Tabellen und Seiten?

Ja, über den Standard-Satz D365 BUS FULL ACCESS. Jede App bindet ihr Berechtigungsset mit einer Erweiterung dieses Satzes ein; die legt die KI an, bei einer App, die noch keine hat, mit ihrem nächsten Ticket. Wer D365 BUS FULL ACCESS hat (etwa mit Essentials-Lizenz) oder D365 BUS PREMIUM, der ihn enthält, bekommt so die Rechte auf neue Tabellen, Seiten und Codeunits; die Plattform selbst weist niemandem etwas zu. Für Benutzer, die nur D365 READ oder D365 TEAM MEMBER haben, gilt das nicht. Das KI-Review prüft die Einbindung, der App-Check zeigt sie, und meldet Business Central für den Testbenutzer des Web-Client-Tests SUPER, warnt das Ergebnis, weil fehlende Rechte so nicht auffallen.

Wie verhindern Sie Konflikte bei Objekt-IDs?

Objekt-IDs, Feldnummern in Tabellenerweiterungen und Enum-Werte vergibt die Plattform selbst aus den ID-Bereichen der App und reserviert sie über alle Branches und alle Apps desselben Tenants; Nummern anderer Per-Tenant-Extensions in Ihren Umgebungen lässt sie aus, und Objekt-IDs vergibt sie On-Premise nur, wo die Lizenz der Instanz sie erlaubt, sofern der Connector die Lizenz lesen konnte. Sonst steht im Job-Log „Lizenz unbekannt: IDs nicht gegen die Lizenz geprüft“. Nach jeder Umsetzung prüft sie die Nummern, Doppelte korrigiert die KI, sonst wird nichts übernommen. Vor jeder Installation prüft sie noch einmal gegen die Umgebung und nennt bei einem Konflikt die andere App und das Objekt, statt dass Business Central die Installation ablehnt. Welche IDs eine App wo verwendet, zeigt eine Tabelle im Code der App.

Was passiert, wenn eine Installation fehlschlägt?

Sie sehen den Fehlertext von Business Central im Log des Tickets, und der Stand der Stufe im Repository wird zurückgesetzt. Das Ticket behält seinen Status, Sie arbeiten nach und rollen erneut aus.

Können wir ein Ticket stornieren, auch wenn es schon live ist?

Ja. Steckt sein Code weder in Test noch in Live, gilt die Stornierung sofort. Sonst nimmt die Plattform ihn dort mit einer Rücknahme heraus: Weil Business Central keine ältere Version annimmt, baut sie die Änderungen des Tickets aus und spielt das Ergebnis als neue, höhere Version ein, aus Live wie jedes Ticket über Test und Abnahme. Haben spätere Tickets dieselben Dateien geändert, zeigt sie das vorher. Sie stornieren diese dann zusammen mit ihm, oder Sie stornieren nur dieses Ticket und lösen die Überschneidungen selbst auf. Hat das Ticket Tabellen oder Felder angelegt, hält die Schemaprüfung die Rücknahme an, weil Business Central deren Entfernen nicht annimmt; dann ändern Sie den Code der Rücknahme selbst, etwa mit ObsoleteState = Pending statt Löschen. Stornierte Tickets bleiben unter „Alle“ und „Storniert“ sichtbar. Ein Ticket, das live und fertig ist, setzen Sie dagegen auf „Erledigt“: Es steht dann nur noch in der Ansicht „Erledigt“, sein Code bleibt live, und „Wieder öffnen“ setzt es zurück auf „Im Live“.

Kann die KI auch Berichtslayouts in Word und Excel ändern?

Ja. Sie fügt Felder und Tabellenspalten ein, ersetzt Texte und Bilder wie das Logo und ergänzt fehlende Werte im Bericht oder in einer Berichtserweiterung, so auch bei Standardberichten von Microsoft. Ein aus Business Central heruntergeladenes Layout hängen Sie einfach ans Ticket. Geändert werden nur die betroffenen Teile der Datei, und das Ticket zeigt den Stand vorher und nachher zum Herunterladen; eine Vorschau als PDF gibt es nicht.

Bekommen unsere Anwender ein Handbuch und Versionshinweise?

Ja, beides. Die KI schreibt für jede App ein deutsches Anwenderhandbuch mit Seiten, Feldern und Abläufen Schritt für Schritt, bebildert mit Screenshots aus dem Web-Client-Test, und hält es nach jeder Installation in Live aktuell. Neue Versionen prüfen und veröffentlichen Sie selbst. Veröffentlicht gibt es das Handbuch als PDF und unter einem Link ohne Anmeldung, den Sie als Hilfe-Adresse der App eintragen können. Ist eine neue Version der App in allen Live-Umgebungen installiert, schreibt die KI außerdem Versionshinweise auf Deutsch oder Englisch: was sich für die Anwender ändert, ohne Ticketnummern und Technik. Standardmäßig gehen sie erst nach Ihrer Prüfung als Mail an eine Liste, die Sie je App pflegen, etwa einen Verteiler des Kunden. Die technischen Mails nach jeder Installation gehen nur an die Projektbeteiligten.

Können wir weiter mit VS Code arbeiten?

Ja. Jede App hat ein Git-Repository, das Sie mit Ihrer E-Mail-Adresse und einem persönlichen Token klonen. Gepusht wird in den Branch des Tickets, die Stände für Test und Live ändert nur die Plattform. Die launch.json für Ihre Umgebungen liefert die Plattform mit: veröffentlichen und debuggen in Entwicklung, anhängen in Test, Snapshot-Debugging in Live. Den Regelsatz der Code-Analyse, den der nächste Build nimmt, laden Sie für VS Code herunter; die Zeilen für die settings.json nennt die Plattform dazu. Die launch.json bleibt in Ihrem Klon und kommt nicht ins Repository, denn jede App schließt den Ordner .vscode in ihrer .gitignore aus. Ohne Klon und Installation öffnen Poweruser den Code auch im Web-Editor im Browser, mit Syntaxfarben für AL, aber ohne AL-Vervollständigung und ohne Gehe zu Definition; dafür bleibt VS Code mit der AL-Erweiterung.

Können wir mehrere Kunden-Tenants verwalten?

Ja. Ein Arbeitsbereich bindet mehrere Business-Central-Tenants und On-Premise-Server an, und jede App gehört zu genau einem davon, mit dessen Umgebungen und Stufen. Die Apps einer Firma fassen Sie zu einem Kunden zusammen und sehen auf seiner Seite seine Umgebungen, die installierten Versionen und die offenen Tickets; Apps und Tickets lassen sich nach Kunde filtern. Gehören Umgebungen eines Tenants oder Instanzen eines Servers verschiedenen Kunden, ordnen Administratoren auf der Seite des Tenants oder Servers jeder Umgebung ihren Kunden zu, einen neuen legen sie dort gleich an. Eine Umgebung mit Kunde bedient dann nur dessen Apps, und eine App zeigt nur die Umgebungen, die sie bedienen.

Wann kommen neue Versionen in unsere Umgebungen?

So, wie Sie es je Umgebung festlegen: sofort nach der Freigabe oder zu festen Terminen, etwa werktags um 22 Uhr in Test und jeden Abend um 18 Uhr in Live. Was bis zum Termin bereitgestellt ist, kommt zusammen als ein Release hinein, danach geht je Ticket eine technische Mail hinaus. Ist die Version danach in allen Live-Umgebungen der App installiert, fassen die Versionshinweise das Release für Ihre Anwender in einer Mail zusammen. Ein Ticket, das auf einem anderen aufbaut, kommt nur mit diesem oder danach. Direkt vor dem Termin prüft die Plattform die Umgebung: Hat sie ein Problem, oder läuft dort ein BC-Update oder startet es keine zwei Stunden neben dem Termin, kommt das Release zum nächsten Termin. Fremde Apps spielen Sie ebenso sofort oder zum Termin ein, zum Termin mit derselben Prüfung davor.

Wie bereiten Sie unsere Apps auf ein großes BC-Update vor?

Mit der Update-Vorschau, für Business Central online. Bietet Microsoft eine neue Hauptversion als Vorschau an oder ist für eine Ihrer Umgebungen das Update auf sie geplant, weist die Karte „Update-Vorschau“ auf der Seite des Tenants darauf hin. Ein Administrator startet dann die Vorschau: Die Plattform kompiliert jede Ihrer Apps des Tenants in einer Sandbox gegen die neue Version, entweder in einer neuen, die sie danach wieder löscht, wenn Sie sie nicht behalten, oder in einer bestehenden, die sie dafür, wenn nötig, nach einer Warnung per Update auf die neue Version bringt oder leer neu anlegt; eine Produktivumgebung nimmt sie nie. Je App zeigt sie die Fehler und Warnungen, die neu dazukommen, mit Datei und Zeile und getrennt von denen, die es heute schon gibt. Daraus legen Sie mit einem Klick ein Ticket an, das den gewohnten Weg über Umsetzung, Test und Abnahme geht. Läuft das Update dann um den Termin eines geplanten Releases, verschiebt die Plattform das Release auf den nächsten Termin. On-Premise gibt es die Update-Vorschau nicht.

Können unsere Anwender die Plattform in Business Central öffnen?

Ja, mit der App ALForge, die die Plattform mit einem Klick je Umgebung installiert. Ihre Anwender finden sie über die Suche (Alt+Q) unter „ALForge“ und melden sich dort mit ihrem Konto der Plattform an, mit Passwort und dem Code aus ihrer Authenticator-App. Die Anmeldung gilt für die Sitzungsdauer der Plattform, als Vorgabe 7 Tage; danach melden sie sich dort neu an. Die App braucht Business Central online ab Version 22.

Wie schützen Sie die Anmeldung an der Plattform?

Mit einem zweiten Faktor für jedes Konto. Bei jeder Anmeldung mit Passwort, auch auf dem Telefon und in Business Central, fragt die Plattform danach den sechsstelligen Code aus einer Authenticator-App ab, etwa aus Microsoft Authenticator oder Google Authenticator; ein „Gerät merken“ gibt es nicht. Eingerichtet wird der zweite Faktor bei der ersten Anmeldung mit einem QR-Code, und überspringen lässt sich das nicht. Danach gibt es zehn Einmal-Codes für den Fall, dass das Telefon fehlt. Nach zu vielen falschen Codes prüft die Plattform eine Viertelstunde lang keinen Code des Kontos. Auch falsche Passwörter bremst sie: Nach 5 falschen für eine E-Mail-Adresse innerhalb von 15 Minuten wartet die Anmeldung mit dieser Adresse 1 Minute, nach jedem weiteren doppelt so lange, höchstens 15 Minuten. Nach 30 falschen Passwörtern von derselben IP-Adresse innerhalb von 15 Minuten, gleich für welche E-Mail-Adressen, wartet jede Anmeldung mit Passwort von dieser IP-Adresse 15 Minuten. Die Bremse gilt auch, wenn jemand mit bestehendem Konto eine Einladung annimmt oder sein Passwort ändert. Ob es zu einer Adresse ein Konto gibt, verrät die Anmeldeseite weder mit ihrer Meldung noch mit ihrer Antwortzeit. Ist das Telefon weg und kein Einmal-Code mehr übrig, setzt ein Administrator die Zwei-Faktor-Anmeldung zurück; das Konto bekommt darüber eine Mail und richtet sie bei der nächsten Anmeldung neu ein. Passkeys, Sicherheitsschlüssel und SMS gibt es nicht. Wie lange eine Anmeldung höchstens gilt, gibt die Plattform für alle Arbeitsbereiche gleich vor, als Vorgabe 7 Tage; dazu kann eine Abmeldung nach Untätigkeit kommen, bei der nicht als Aktivität zählt, was eine offene Seite von selbst nachlädt. Kürzt die Plattform die Dauer oder ändert sie die Abmeldung nach Untätigkeit, gilt das sofort auch für laufende Anmeldungen und in Business Central. Nach dem Ablauf nennt die Anmeldeseite den Grund, und nach der neuen Anmeldung geht es zur Seite von vorher zurück. Im Browser hält HSTS die Verbindung zur Plattform auf HTTPS, und eine Content-Security-Policy lässt nur Skripte der Plattform laufen.

Können Key-User und Anwender fragen, was eine App macht?

Ja. Key-User fragen im Reiter „Fragen“ jeder App, auch in der einfachen Ansicht und aus Business Central heraus. Die KI antwortet aus dem Code und den Tickets der App, etwa wo ein Rabatt berechnet wird oder was Ticket 12 geändert hat, und nennt die Dateien und Tickets, auf die sie sich stützt. Daten aus Business Central liest sie nicht, und jede Frage steht mit ihren Kosten im Verbrauchsprotokoll. Auch ohne Konto der Plattform können Ihre Anwender eine Frage per Mail an das Postfach schicken, das die Plattform liest, etwa wie sie eine Gutschrift mit Bonus buchen. Dafür muss der Autopilot der App eingeschaltet sein, ihre Adresse oder Domain bei der App unter „Dürfen Fragen stellen“ stehen und die Mail die DMARC-Prüfung bestehen oder angemeldet aus dem Microsoft-365-Mandanten des Postfachs kommen. Der Autopilot antwortet in der Sprache der Mail im selben Mailverlauf, ohne Code und Dateinamen, gestützt auf das veröffentlichte Handbuch, den Code in Live und nur die Anforderungen der App, die der Fragende sehen darf: seine eigenen und, wenn die Plattform ihn einem Kunden zuordnet, die dieses Kunden. Von diesen liest die KI nur Titel, Status, Version, Termine und die gesendeten Versionshinweise, Beschreibung und Akzeptanzkriterien nur bei seinen eigenen; Verlauf, Konzept, Namen von Mitgliedern und Anforderungen anderer Kunden bekommt sie dafür nie. Unten in der Antwort steht, dass eine KI sie geschrieben hat und ob jemand sie geprüft hat. Wenn die KI unsicher ist, eine Antwort zur App nicht belegen kann oder Daten aus Business Central braucht, etwa zu einem bestimmten Auftrag, schreibt sie nur einen Entwurf, den Sie prüfen und abschicken. Allgemeine Fragen zu Business Central beantwortet sie, wenn sie sicher ist, mit dem Hinweis, dass die Antwort den Standard beschreibt. Auf zwei Nachfragen antwortet die KI noch selbst, ab der dritten antworten Sie. In der Grundeinstellung gehen sichere Antworten ohne Prüfung hinaus; wer vorsichtig beginnen will, nimmt bei der App den Haken „Antwort senden“ heraus, dann wird jede Antwort ein Entwurf.