[gelöst]Entwicklungskonzept

Bild Microsoft Dynamics 365 Business Central (On-Premises Version)
Forumsregeln
Impressum • Community-Knigge • Nutzungsbedingungen • Datenschutzrichtlinie

Bitte unbedingt im Titel angeben, auf welche Version (BC13, BC14, BC15, ...) sich eure Frage bezieht!

[gelöst]Entwicklungskonzept

Beitragvon elf » 29. August 2019 12:10

Hi Allerseits,

wir werden in Kürze 365BC on Premises bei uns einsetzen. Da die Möglichkeit bestehen bleiben soll, evtl. später in die Cloud (SaaS) zu gehen, soll die Entwicklung von Anpassungen in Extensions gemacht werden, nichts in C/Side.

Wir sind drei Entwickler und entwickeln ausschlieĂźlich zur eigenen Nutzung. Bisher haben wir eine Entwicklungsdatenbank mit Nav3.6, auf der die Objekte angepasst wurden, bzw. neue Obbjekte entwickelt wurden. Wenn ein Entwickler ein Objekt bearbeitet, dann "sperrt" er es, indem er sein NamenskĂĽrzel in die Versionsliste hineinschreibt. Nach Test werden dann alle Objekte als .fob exportiert und dann in die Echt-Datenbank importiert. Das funktioniert soweit ganz gut und hat noch nie zu Problemen gefĂĽhrt, setzt allerdings ein gewisses MaĂź an Disziplin voraus.

Wir grĂĽbeln jetzt ĂĽber ein Konzept fĂĽr die Extension-Entwicklung.

Wie sollten wir die Extension(s) aufbauen ?

Ist es sinnvoll, eine große Extension für alles zu machen, also alle Anpassungen in einer einzigen Extension zu haben. Oder sollten wir besser einzelne Bereiche mit eigenen Extensions machen? Es wird sehr oft Überschneidungen zwischen den Bereichen geben, aber da kann man ja mit Dependencies arbeiten. Oder ist es gar vorstellbar, für jede erweiterte Table eine eigene Extension (Table und dazu gehörende Pages) zu machen. Auf diese Art findet jeder sofort die Quelle eines Feldes und braucht nicht zu grübeln, in welcher der Extensions ein Feld definiert wurde.

Wie gesagt, wir arbeiten nur für uns, brauchen also keine Rücksicht auf Vermarktungsfähigkeit etc. zu nehmen.
Zuletzt geändert von elf am 4. September 2019 12:16, insgesamt 1-mal geändert.
GruĂź aus Zossen bei Berlin
Eddie
Benutzeravatar
elf
 
Beiträge: 220
Registriert: 21. Dezember 2006 15:15
Wohnort: Zossen bei Berlin
Realer Name: Edgar Leifeld
Arbeitsort: Zossen bei Berlin
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV / BC

Re: Entwicklungskonzept

Beitragvon Ted » 29. August 2019 14:04

Es gibt in meinen Augen nur 2 Möglichkeiten als Endnutzer.
Beides hat vor und nachteile, wobei ersteres leichter zu handhaben ist, das Zweite allerdings mehr flexibilitaet bietet

1. Eine Extension fĂĽr alles
Vorteile:
- du musst dir keine Gedanken darum machen in welche App du jetzt welche Funktion packst. Du hast keine Dependencies!
- es unterscheidet sich nicht all zu sehr von der C/Side Entwicklung. Eine Datenbank -> eine App
Nachteil
- es wird sehr schnell sehr unübersichtlich wenn die Extension größer wird.
- du kannst nicht einfach Tabellen/Tabellenstrukturen refactoren.
- "Quickfixes" im laufenden Betrieb sind hiermiet fast unmöglich.

2. Eine Extension fĂĽr logisch abtrennbare Module
Vorteil:
- solltest du mehrer Datenbanken besitzen kannst du entscheiden ob du ein Modul in der Datenbank benötigst. Vor allem wenn du mehrere Länderversionen hast.
- du kannst ein Modul komplett aus der Datenbank entfernen wenn es nicht mehr benötigt wird. (oder es leicht refactoren).
- sind in der Regel recht klein und damit ĂĽbersichtlich.
Nachteil:
- du musst dich mit Dependencies rumschlage, dies kann vor allem in Entwicklungsumgebungen sehr nervig werden.
- du musst Entscheidungen Treffen wo du bestimmte Funktionen implementierst (als Beispiel brauchst du in einer App ne OAuth authentifizierung - wo packst du die Logik dafĂĽr hin?)
- für die installation der untersten App musst du alle Apps die eine abhängigkeit haben deinstallieren
- du musst deine ObjektID's irgendwie verwalten

Wir haben uns fĂĽr Variante 2 entschieden. Ich hab im laufe der letzten 2 Jahre jede Menge Powershell Scripte entwickelt welche uns mit den meisten Nachteilen helfen.
Bei uns entwickelt jeder Entwickler lokal in seiner eigenen Instanz (auch App ĂĽbergreifend). Wenn er fertig ist, wird der Code in die Versionskontrolle geschoben und automatisiert in ein Testsystem geschoben.
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: Entwicklungskonzept

Beitragvon Timo Lässer » 29. August 2019 14:09

Früher war die Application noch überschaubar, und wenn man sehen wollte, wo was angepasst wurde, öffnete man das Objekt im Designer und schaute in dem Trigger/Feld einfach nach.
Navision/NAV/D365BC wurde mit der Zeit aber immer komplexer und spätestens mit der Einführung der Events kann man auch nicht "mal eben" nachschauen, ob das Objekt angepasst wurde.

Ich empfehle daher auf jeden Fall den Einsatz von Tools wie den "Object Manager Advanced".
(Ehrlich gesagt, kann ich mir heute nicht mehr vorstellen, dass man frĂĽher ohne ein solches Tool in einem ERP-System programmiert hat.)
Die aktuelle Version 13 des Object Manager Advanced unterstĂĽtzt auch C/AL <-> AL Konvertierungen on-the-fly.
Gruß, Timo Lässer

Frage beantwortet? Schreibe bitte "[Gelöst]" vor den Titel deines ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, E-Mail, Instant Messanger, Soziale Netzwerke, Telefon oder Fax! DafĂĽr ist dieses Forum da.
Hier kannst du fĂĽr MSDynamics.de spenden.
Benutzeravatar
Timo Lässer
Administrator
Administrator
 
Beiträge: 5274
Registriert: 14. November 2004 22:18
Wohnort: DE 49716 Meppen
Arbeitsort: DE 49733 Haren (Ems)
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 1.10a - 2018, BC14, BC21

Re: Entwicklungskonzept

Beitragvon elf » 29. August 2019 16:14

ok, danke,

alles in eine einzige Extension zu packen scheint uns tatsächlich nicht der beste Weg zu sein. Da wir ziemlich nah am Anwender sitzen, machen wir oft mal Quickfixes - das wäre dann wahrscheinlich wirklich sehr schwierig zu bewerkstelligen.

Wir überlegen jetzt, eine eigenständige Extension für jede Table zu machen. In dieser Extension wären dann die Felder der Table, die Extension für die Karte und die Liste drin. So wäre es relativ einfach, Änderungen an Tables "aufzuspüren", man müsste nicht schauen, in welcher Extension welches Feld hinzugefügt bzw. geändert wurde. Allerdings bläht das natürlich die Anzahl der installierten Extensions und der Dependencies auf. Würde das ein Problem bereiten?
GruĂź aus Zossen bei Berlin
Eddie
Benutzeravatar
elf
 
Beiträge: 220
Registriert: 21. Dezember 2006 15:15
Wohnort: Zossen bei Berlin
Realer Name: Edgar Leifeld
Arbeitsort: Zossen bei Berlin
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV / BC

Re: Entwicklungskonzept

Beitragvon sweikelt » 29. August 2019 18:11

elf hat geschrieben:WĂĽrde das ein Problem bereiten?


schwierig zu sagen, da es sicherlich noch kein Livebeispiel gibt, wieviele Extensions das System problemlos verkraftet - ich denke es klappt, aber wie du schon sagtest, bläht das alles ungemein auf.
Benutzeravatar
sweikelt
Microsoft Partner
Microsoft Partner
 
Beiträge: 1776
Registriert: 18. November 2010 10:15
Wohnort: Oschatz
Realer Name: Stephan Weikelt
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 3-2018 | D365BC

Re: Entwicklungskonzept

Beitragvon enh » 30. August 2019 20:06

M. E. macht 1 Extension pro Tabelle keinen Sinn da i. d. R. ja mehr zu einer Anpassung gehört als eine Tabelle mit zugehöriger/n Page(s).

Beispiel: Neues Feld im Debitor dass in den Verkaufsbeleg übertragen werden soll und mitgebucht werden soll. Es ist kein einfaches Feld (kein transferfields) sondern soll in bestimmten Abhängigkeiten beim Buchen unterschiedliche Dinge bewirken. Ich setze auch mal voraus dass es in der Buchungsfunktion/Codeunit ein passendes Event gibt und hier nur Code ergänzt, nicht Standard-Code geändert werden soll. Dann wären mehrere Tabellen, Pages, Codeunit(s) von der Anpassung betroffen. Diese Anpassung dann in z. B. 3 Extensions zu verteilen (pro Tabelle und Codeunit) macht m. E. keinen Sinn.
enh
 
Beiträge: 2330
Registriert: 5. Februar 2014 15:42
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Re: Entwicklungskonzept

Beitragvon elf » 2. September 2019 11:19

M. E. macht 1 Extension pro Tabelle keinen Sinn da i. d. R. ja mehr zu einer Anpassung gehört als eine Tabelle mit zugehöriger/n Page(s).


Ja, das ist uns schon bewusst. Grundsätzlich halten wir es auch für sinnvoller, die Extensions nach Inhalten zu bauen. Also alle Dinge einer neuen Funktion (neue Pages, Reports, Codeunits etc.), in einer eigenen Extension zusammenzufassen. Nun gibt es bei uns aber auch Felder - im Wesentlichen im Customer- und ItemTable - die übergreifend in sehr vielen Bereichen benutzt werden. So haben wir z.B. derzeit im Customer ein zusätzliches Feld "Name 3". Dieses Feld könnten wir keinem Bereich explizit zuordnen. Wir müssten also eine Basis-Extension haben, in der die grundsätzlichen zusätzlichen Tabellenfelder definiert werden würden. Wir müssten dann bei jedem neuen Feld überlegen, ob dieses Feld evtl. später mal in einer anderen Extension auch benötigt werden könnte, um zu entscheiden, ob es in die Basis-Extension hineinkommt oder einer bestimmten Extension explizit zugeordnet ist. Wie schon gesagt, wir entwickeln nur für den Eigenbedarf.

Wenn wir je Tabelle eine eigene Extension machen, dann werden das vielleicht tatsächlich zu viele Extensions mit sehr vielen Dependencies in den darauf zugreifenden Extensions. Vielleicht ist es sinnvoller, eine Extension für alle Tables und die dazu gehörigen Pages (Stammdatenkarte und -Übersicht) zu benutzen.

Wir sind da noch in der Findungsphase...
GruĂź aus Zossen bei Berlin
Eddie
Benutzeravatar
elf
 
Beiträge: 220
Registriert: 21. Dezember 2006 15:15
Wohnort: Zossen bei Berlin
Realer Name: Edgar Leifeld
Arbeitsort: Zossen bei Berlin
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV / BC

Re: Entwicklungskonzept

Beitragvon elf » 4. September 2019 12:16

ok, wir haben jetzt - vorerst - entschieden, alles in einer einzigen Extension zu machen. Das scheint uns am einfachsten, und wir sparen uns das Dependencies-Gedöns. Es sei denn, es gibt eigenständige, komplett unabhängige Bereiche, die werden dann eigene Extensions bekommen.

Hotfixe dürften auch relativ problemlos sein. Wir werden die Struktur so gestalten, dass jedes Objekt eine eigene Datei erhält. Jeder Entwickler hat eine Kopie der kompletten Codebasis in seiner Entwicklungsumgebung. Bei Hotfixen werden im Projekt halt diese zu tauschenden Dateien ausgetauscht und es wird kompiliert und installiert.
GruĂź aus Zossen bei Berlin
Eddie
Benutzeravatar
elf
 
Beiträge: 220
Registriert: 21. Dezember 2006 15:15
Wohnort: Zossen bei Berlin
Realer Name: Edgar Leifeld
Arbeitsort: Zossen bei Berlin
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV / BC

Re: Entwicklungskonzept

Beitragvon Ted » 4. September 2019 14:00

elf hat geschrieben:Bei Hotfixen werden im Projekt halt diese zu tauschenden Dateien ausgetauscht und es wird kompiliert und installiert.


Denkt bitte daran, wenn ihr eine neue Version einer Extension installieren wollt, muss dafĂĽr die alte Version deinstalliert werden.
Dies sollte nur geschehen wenn kein Benutzer im System ist, oder du 100% sicherstellen kannst das die Benutzer keine Objekte von der Extension nutzen die du jetzt deinstallierst.

D.h. schnell mal nen Objekt wie in C/Side zu ändern ist so nicht möglich!
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: [gelöst]Entwicklungskonzept

Beitragvon elf » 4. September 2019 14:14

Denkt bitte daran, wenn ihr eine neue Version einer Extension installieren wollt, muss dafĂĽr die alte Version deinstalliert werden.


Muss die Extension wirklich deinstalliert werden? Oder ist das über die Versionsnummer gesteuert? Wenn wir die Versionsnummer in der app.json nicht ändern, muss dann die Extension wirklich zunächst deinstalliert werden?

Aber i.d.R. installieren wir Updates eh am Abend. Das war bisher in Nav auch so: wenn eine Table geändert wurde, dann sind die Benutzer auch rausgeflogen..
GruĂź aus Zossen bei Berlin
Eddie
Benutzeravatar
elf
 
Beiträge: 220
Registriert: 21. Dezember 2006 15:15
Wohnort: Zossen bei Berlin
Realer Name: Edgar Leifeld
Arbeitsort: Zossen bei Berlin
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV / BC

Re: [gelöst]Entwicklungskonzept

Beitragvon fiddi » 4. September 2019 16:03

Hallo,
Aber i.d.R. installieren wir Updates eh am Abend.

Du hast da ein ganz wichtigen Zusatz gemacht-> i.d.R. .

Wenn es ein gravierendes Problem gibt, wirst du sofort handeln müssen, und nicht bis abends warten können. Gerade am Anfang wird sicherlich häufiger passieren.

GruĂź Fiddi
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7091
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: [gelöst]Entwicklungskonzept

Beitragvon elf » 4. September 2019 17:11

na klar, wenn das Problem so gravierend ist, dass es nicht bis zum Abend warten kann, dann mĂĽssen halt zur Not alle User raus..
GruĂź aus Zossen bei Berlin
Eddie
Benutzeravatar
elf
 
Beiträge: 220
Registriert: 21. Dezember 2006 15:15
Wohnort: Zossen bei Berlin
Realer Name: Edgar Leifeld
Arbeitsort: Zossen bei Berlin
Bezug zu Microsoft Dynamics: Freiberufler
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV / BC

Re: [gelöst]Entwicklungskonzept

Beitragvon m_schneider » 5. September 2019 09:35

elf hat geschrieben:Muss die Extension wirklich deinstalliert werden? Oder ist das über die Versionsnummer gesteuert? Wenn wir die Versionsnummer in der app.json nicht ändern, muss dann die Extension wirklich zunächst deinstalliert werden?

WeiĂź das einer?
MfG Michael
Benutzeravatar
m_schneider
 
Beiträge: 2141
Registriert: 20. Januar 2009 14:36
Realer Name: Michael Schneider
Arbeitsort: Treuen
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2017

Re: [gelöst]Entwicklungskonzept

Beitragvon Ted » 5. September 2019 09:58

m_schneider hat geschrieben:WeiĂź das einer?


Wenn du versucht die Extension noch einmal ĂĽber Powershell zu publishen bekommst du folgenden Fehler
Code: Alles auswählen
Publish-NAVApp : This Extension cannot be published as it is already published.
At line:11 char:7
+       Publish-NAVApp -ServerInstance $Serverinstance -Path $AppFile.F ...

SO funktioniert es zumindest nicht.


Allerdings kann VSCode ja auch ĂĽber F5 die gleiche Version noch einmal mit "Synchronize" oder "Recreate" publishen.
Der F5 Button benutzt den DEV Endpoint (wie der genau funktioniert kann ich dir allerdings nicht sagen)
Wenn du aber beim F5 drĂĽcken die Extension Liste offen hast, siehst du das die Extension erst deinstalliert, unpublished und dann neu gepublished und installiert wird.
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: Entwicklungskonzept

Beitragvon Kowa » 21. Juli 2021 11:51

Timo Lässer hat geschrieben:Die aktuelle Version 13 des Object Manager Advanced unterstützt auch C/AL <-> AL Konvertierungen on-the-fly.

Die kommende Version OMA 365 (Beta ab August) wird die erste AL-basierte sein, verwendbar ab BC 15 aufwärts.
GruĂź, Kai

Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, Messenger oder Telefon! DafĂĽr ist dieses Forum da.

Download: Dynamics NAV Object Text Explorer (Alternativlink). MVP Alumni
Benutzeravatar
Kowa
Moderator
Moderator
 
Beiträge: 7835
Registriert: 17. Juni 2005 17:32
Wohnort: Bremen
Realer Name: Kai Kowalewski
Arbeitsort: Osterholz-Scharmbeck
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics 365
Microsoft Dynamics Version: BC, NAV 2018 bis Navision 2.01


ZurĂĽck zu 365 Business Central (On-Premises)

Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 1 Gast