Grundlegende Infos zur Sage Entwicklung

[Bennet]

Hallo zusammen,

ich komme ursprünglich aus der Software Entwicklung und bin mittlerweile bei einem Systemhaus, das die Sage 100 einsetzt.
Mit der Entwickler-Brille ergeben sich intern immer wieder Dinge, die ich gerne optimieren würde. Aus diesem Grund habe ich mich (auch viel in diesem Forum) mal umgeschaut, wie die Entwicklung von Sage Addons so abläuft.

Und um ehrlich zu sein blicke ich einfach nicht durch. Oft wird von einem Kochbuch mit Rezepten gesprochen, es gibt den AppDesigner und die "alte Technologie", man kann Addons scheinbar in verschiedensten Programmiersprachen entwickeln, mal braucht man eine "Entwicklerlizenz", manchmal kann man einfach loslegen.

Ich wäre sehr dankbar, wenn mich jemand mal kurz abholen könnte, was der aktuelle best practice ist, um programmatisch Anpassungen / Zusatzfunktionen für die Sage 100 zu entwickeln und welche Voraussetzungen dafür erfüllt sein müssen.

Lieben Dank vorab!

 

[breithecker]

ich bin zwar kein Entwickler aber ich versuche mich mal darin, dir zu helfen (gerne dürfen die Entwickler hier ergänzen oder korrigieren).

Du hast in und mit der Sage 100 mehrere Möglichkeiten:

1. Entwicklung innerhalb der Sage 100 mit den von Sage bereitgestellten Mitteln - das wäre dann über den sogenannten AppDesigner. Hierfür gibt es eine Entwicklerlizenz. Damit kann ein Kunde oder auch ein "Nicht-Sage-Partner" Anpassungen vornehmen. Hier wird oft auf das Kochbuch verwiesen - das ist ein Handbuch aus den Schulungen von Sage.
Vielleicht hilft dir folgender Link: https://sagegmbh.atlassian.net/wiki/spaces/S1/pages/19038211/AppDesigner
Alternativ gibt es hierzu auch Schulungen - über Sage Partner oder teilweise auch über Sage direkt.

2. alte Technologie: damit sind in der Regel sogenannte Addins gemeint. Programmierung auf Basis von Access, die ebenfalls direkt in der Sage 100 laufen. Hierfür gibt oder zumindest gab es früher auch immer eine Vorlage von Sage um Erweiterungen zu machen. Nach meinem Verständnis sollte man das heute eher lassen - Access fliegt ja raus.

3. Programmierungen in der Sage 100 mit anderen Programmiersprachen/-Tool wie dem AppDesigner. Auch das geht wohl - ich weiß, dass wir das in Teilen auch machen. Manchmal gibt es Punkte die kann der AppDesigner (noch) nicht. Hier wird wohl häufig mit DevExpress, etc gearbeitet.

4. Programmierungen außerhalb der Sage 100 - hier sind dir aus meiner nahezu keine Grenzen gesetzt. Es gibt auch hier fertige Entwicklungswerkzeuge, wenn du zum Beispiel Programmierungen machen willst die in M365 oder dem Browser laufen, kannst du das recht simpel mit mydatastream machen. Du kannst aber auch jede andere Programmiersprache nehmen und lesend und schreibend auf die Sage 100 zugreifen - wahlweise über die API (https://sagegmbh.atlassian.net/wiki/spaces/S1/pages/2628190209) oder über einen direkten Datenbankzugriff auf Tabellenebene.

Ich hoffe das hilft dir - ich bin wie gesagt keinen Entwickler - kann aber gerne einen Kontakt herstellen. Meine Zusammenfassung ist sicher nicht vollständig aber ich denke es hilft für eine erste Orientierung.

Viele Grüße

Sascha

 

[mgosx]

Hallo Bennet,
die Sage Officeline gibt es seit ca. 30 Jahren.Historisch bedingt lief und läuft diese noch in Access mit Access-Addins (als Anpassungsmöglichkeit). Die eigentliche Geschäftslogik ist ausgelagert in DLLs. Irgendwann wurde dann ein Application Server dazwischen geschaltet auf dem dem gewisse Geschäfslogik abläuft.

Seit ca. 10 Jahren erfolgt die Umstellungen auf eine saubere Trennung von Datenbank-Abfragen, Geschäftslogik und GUI, mit dem Ziel Access in ca. 15 Monaten dann komplett anzuschalten / zu ersetzen.

Hierzu sind innerhalb der Entwicklung quasi nachfolgende Komponenten / Vorgehensweisen ideal:

AppDesigner:
In diesem können alle Datenabfragen (egal ob schreibend, lesend, Datensatzbasiert, Abfragen) definiert werden und mit GUI-Elementen verbunden werden. Im AppDesigner können auch Makros ablaufen, aufwendigere Programmierungen kann man in C# / .net erstellen. Diese laufen in der Regel zentral auf dem ApplicationServer ab.

Der AppDesigner ist recht mächtig, insbesondere erlaubt er das man sich an Lösungen anhängen kann und Erweiterungen update-sicher umsetzen kann.
Viele Änderungen (Abfragen auch mit Filtern etc., neue Felder in DB und GUI, Abhängigkeiten von Feldern, Validierungen etc.) sind ohne Code einfach umsetzbar.
Die eigentliche Funktion lässt sich dann z. B. über ein C# MacroProcessBase Aufruf umsetzen, der dann Manipulationen und Berechnungen ausführt und die Ergebnisse an ein Macro im AppDesigner zurück liefert.

Report-Designer:
Anpassungen der Druck-Ausgaben

Visual Studio:
Wichtigste Objekte zur Anpassungen sind:

- Geschäftsprozesse
diese erlauben es das Ergebnis einer SQL-Abfrage zu verarbeiten (ergänzen, löschen o. hinzufügen von Zeilen) bevor diese dann an den Client gehen.

- MacroProcessBase
werden vom AppDesigner aufgerufen, führen serverseitig befehle aus und liefern das Ergebnis zurück

- Komplexe Datenobjekte
Man kann auch das kompletten Laden, Speichern eines komplexen Objektes wie einen VKBeleg in eigenem Code erstellen inkl. aller Abhängigkeiten und der Geschäftslogik

- DCMs
DCMs werden in der App ausgelöst bei bestimmten Ereignissen (ReportBeforePrint, VKBelegPositionBeforeSave, VKBelegAfterSave...). Es gibt ein spezielles DCM Handbuch, dort sind diese aufgeführt.
Man kann sich dann quasi anhängen und zusätzliche Berechnungen durchführen.

- Client-seitige DLLs
Die meisten der o.g. Dlls werden serverseitig ausgeführt. Für bestimmte Anwendungsszenarien wie Kassenschubladen o.ä. kann man auch clientseitige Dlls erstellen.



Ausserhalb dieser Entwicklung ist die API wie beschrieben auch sehr interessant. Die Endpunkte lassen sich über den AppDesigner anlegen, der Zugriff auf diese ist in jeder Programmiersprache / Umgebung möglich. Ich habe z. B. eine Lösung in Swift für IOS/Ipads zur papierlosen Logistik (Kommissionierung, Chargenentnahme, LS-Erzeugung) erstellt.#


Die genannte Dokumentation (Kochbuch mit Beispielen, Entwicklungshandbuch, Liste der DCMs...) erhält man als Sage Entwicklungspartner. Ohne dies ist es sehr schwierig.

Grüsse Mark