App Strategie BC OnPrem

Hi,

wir planen ein Update OnPrem zum aktuellen BC 27 oder später BC28. Bei der Gelegenheit möchte ich einmal über unser APP Aufbau nachdenken und ihn ggf. ändern.
Aktuell haben wir für alle Standorte eine W1 APP, darüber liegen die lokalen APPs 1. beinhaltet ausschließlich Tabellen(Extensions) / Pages / Query und zentrale Codeunits und Enums(Extensions).
darüber liegt eine Report APP in der ausschließlich Reports(Extensions) sind. Darüber liegt dann der Rest in einer APP im Pageextension und Codeunits und XML Ports.
Hintergrund war der, auch mal APPs einspielen zu können ohne gleich alle Dienste neu starten zu müssen. Damals musst man nur bei Tabellenänderungen die Dienste neu starten. Seit etwa 2 Jahren muss ich das nach dem einspielen von jeder APP. Evtl. kam das mit einem WindowsUpdate !?
Somit ist der Grund zu trennen / bzw. alle Daten in einer APP zu haben hinfällig geworden.

Wie macht ihr das ?
Alles in einer APP?
Oder nach Abteilungen VK / VK usw.

Gibt es noch andere Strategien?

Schon mal besten Dank für neue Anregungen


Frank

In welcher Version seid ihr derzeit? Eigentlich muss man den Dienst nicht neu starten nach dem Update einer Erweiterung. Sinn macht es aber schon, insbesondere wenn das Update länger läuft, dann sollte man vorher nämlich dafür sorgen dass kein Anwender mehr aktiv ist.

Grundsätzlich macht es schon Sinn Tables und TableExtensions zu separieren, weil da beim Update wirklich keine Anwender aktiv sein sollten. Ansonsten ist es eine Frage der Handhabung. Zu viel in einer Extension macht die Sache langsam, auch beim Entwickeln in VS Code. Zu viele kleine Extensions sind auch unhandlich.

Aktuell sind wir auf BC19
Vor etwa 2 Jahren mussten die Dienste auch nur neu gestartet werden wenn die Tabellen APP eingespielt wurde.
Aktuell gibt es Probleme mit BC in der Form dass einige Seiten nicht mehr aufgerufen werden können und statt dessen der Standard BC Fehler Fehler erscheint.
Vllt. geht das mit den neuen Versionen ja besser.
Trotzdem ist das Handling mit den APPs in der aktuellen Form umständlich.

ein Windowsupdate hat damit nichts zu tun.

wenn du von damals sprichst, meinst du zufällig BC14 (und darunter)?
Aber eigentlich egal. Ich starte nie die Dienste nach einem App-Update neu - würde mich also brennend interessieren, warum das bei euch so sein muss
Weiterhin macht es aus meiner Sicht keinen Sinn, die TableExt / Tables separat zu haben - der Anwender sollte so oder so eins ins Gesicht bekommen ("Der Administrator hat schlimme Dinge getan, bitte neu laden"), wenn während der Prod-Zeit eine App eingespielt wird - kann also enh nicht zustimmen. möglich das ich mich täusche!

Alles in eine App zu packen, macht aus meiner Sicht recht wenig Sinn - so ne riesige Monolith-App kann schon weh tun.
Für unsere Kundenanpassungen teile ich das meist in Blöcke auf, wobei die Blöcke eher nach Verwendung /Modulen erstellt werden.
Beispiel:
- Core -> beinhaltet die meiste Funktionalität, gern auch mit Reports etc.
- CoolStuff -> beinhaltet ein Modul, was lustige Dinge tut, aber nicht zwingend in der Core sein muss [wenn möglich auch nicht von der Core abhängig ist]
- APIx -> für irgendwelche APIs, die angesteuert werden müssen
- APIy -> für irgendwelche APIs, die angesteuert werden müssen
- 3rdParty-App-Extensions -> Erweiterungen für z.B. Continia, OPP, BliBlaBlub -> jeweils eine App
=> hat der Vorteil, dass wenn ich was an der Core machen muss, in meine Container nicht zwingend die 3rd Party Apps einspielen muss, damit ich compilen kann.
==> die o.g. Namen sind natürlich nur Beispiele!

Du willst natürlich nicht unbedingt 30 Extensions haben, also sollte man schon nachdenken, was separiert gehört.
Pauschal lässt sich das nicht so wirklich beantworten ...ich denke das ist eher so eine Bauchsache.

Edit:

statt dessen der Standard BC Fehler Fehler erscheint

welcher denn?
Wurde denn dabei mal versucht, den CLIENT neuzustarten? Ich meine BC19 ist schon 2 Tage alt, daher kann ich leider nicht viel zu diesem Verhalten sagen.

Trotzdem ist das Handling mit den APPs in der aktuellen Form umständlich.

Was ist unhandlich?`

Das installieren/updaten? -> Dafür sollte man Scripte nutzen.
Den COde zu warten? -> das wird in einer großen App auch nicht anders

Damals war tatsächlich mit dem aktuellen BC19 von einem Tag auf den anderen.
Die Meldung kann ich leider nicht auslösen da ich SUPER rechte habe.
Die Meldung ist eher nichtssagend "Es ist ein Fehleraufgetreten..." Erscheint nur bei bestimmten Seiten, und ist auch nach Browserneustart noch da. Geht erst nach Dienstneustart weg.

30 APPs will man nicht, das ist klar. 1 ist mir auch zu wenig,
Ich dachte an Abteilungen VK / EK / QS usw.
Die Tabellen/Extension würden erstmal in einer Tabellen APP bleiben, da der Partner auch Anpassungen macht und so die Abhängigkeiten reduziert werden.

Aber wenn ich ein etwas größeres Projekt mache suche ich, nachdem das von den Users getestet worden ist mir durch alle APPs den Quellcode zusammen der gemergt werden muss.
Eine Versionlist wie in NAV gibt es ja nicht mehr.

Die Meldung ist eher nichtssagend "Es ist ein Fehleraufgetreten..." Erscheint nur bei bestimmten Seiten, und ist auch nach Browserneustart noch da. Geht erst nach Dienstneustart weg.

Ich würde erwarten mit Client Neustart müsste das auch funktionieren, mindestens ab- und neu anmelden, besser noch den Browser schließen.

Weiterhin macht es aus meiner Sicht keinen Sinn, die TableExt / Tables separat zu haben - der Anwender sollte so oder so eins ins Gesicht bekommen ("Der Administrator hat schlimme Dinge getan, bitte neu laden"), wenn während der Prod-Zeit eine App eingespielt wird - kann also enh nicht zustimmen. möglich das ich mich täusche!

Ich meine die Meldung kommt nur bei Tabellenänderungen, nicht wenn Pages oder andere Objekte geändert wurden. Ich meine das ist heute auch nicht anders als in der C/AL Welt.

Hallo,

Grundsätzlich solltest du /musst du für jede externe APP, die du benutzen musst/möchtest eine zusätzliche APP haben, wenn du nicht zwingend davon ausgehen kannst, das diese externe APP immer installiert ist, sonnst kannst du deine APP nicht installieren, wenn die externe APP nicht da ist. (mit spezieller Programmierung kann man evtl. drum herum kommen, aber auch das ist Aufwand)

Ich bin allerdings eher ein Freund des Monolithen, es sei denn, du kannst Funktionalität wirklich sauber trennen. Ansonsten verzettelst du dich leicht, wenn du Daten durch zig Ebenen von abhängigen Apps schleusen musst, die dann u.U. nicht geändert werden können, weil Breaking Change.

Wenn du dem Benutzer dann nur Zugriff auf einen Teil der Funktionalität gewähren möchtest, generierst du eine Entitlement-App (Lizenz), die Berechtigungen für einzelne Module vergibt. Das funktioniert dann so ähnlich wie im NAV.
Bei der Programmierung musst du nur beachten, dass du nicht auf nicht lizensierte Bereiche zugreifst.

Aber es gibt da nicht Schwarz und Weiß. Es mach u.U. Sinn Funktionalitäten, die häufiger geändert werden (müssen) in zusätzliche Apps auszulagern (Berichte, Schnittstellen zu externen Systemen,...)

Gruß Fiddi

Ich meine die Meldung kommt nur bei Tabellenänderungen, nicht wenn Pages oder andere Objekte geändert wurden. Ich meine das ist heute auch nicht anders als in der C/AL Welt.

Die kommt immer, weil ja immer die ganze App für alle User durch eine neue Version ersetzt wird. Bei C/AL wurden nur selektiv die betroffenen Objekte geändert, und das wirkte sich nur bei den Usern aus, welche genau diese im Einsatz hatten. Bei Hybridentwicklung in BC 14 (also sowohl mit AL und C/AL) merkt man, dass C/AL hier deutlich angenehmer ist, wenn man tagsüber am Echtsystem kleine Änderungen vornimmt, während hunderte von Usern damit arbeiten. Das sollte man natürlich versuchen zu vermeiden, aber das ist der Unterschied zwischen Theorie und Praxis.

Stimmt, logisch, Kowa hat recht!

Ich arbeite gerade an einem Upgrade in die SaaS, und für unsere PTE verfolgen wir einen ähnlichen Ansatz, wie ihn Fiddi beschrieben hat.
Wir haben eine „BaseApp“ als Monolith, um Abhängigkeitsprobleme zu vermeiden. Innerhalb der PTE trennen wir den Quellcode jedoch klar über Ordnerstrukturen und Namespaces. Damit fahren wir derzeit sehr gut.

Für Schnittstellen und unsere mobile Lösung haben wir allerdings eigene Apps, die wiederum von der internen BaseApp abhängig sind.

Am Ende ist das sicher auch eine Frage der Architektur-Philosophie.
Ein interessanter Blogbeitrag zu diesem Thema:
https://blog.kine.cz/posts/ptearchitecture1/