OFFICIUM INSERVIO
Your reliable partner for your business software...
Auskunft parametriert aus AddIn aufrufen / call list with parameters from AddIn
(alle Versionen/all versions)
Freitag, 12. November 2021
Mögliche Probleme / Possible problems
Hintergrund/Background
Aufruf einer Sage AppDesigner-Auskunft aus einem Sage 100 Microsoft Access-AddIn mit Parametern.
Die entsprechende AppDesigner-Auskunft hat einen vorgeschalteten Selektionsdialog (Selektionselement), der beim Aufruf aus dem Access-AddIn nicht angezeigt werde soll, da die Parameter durch den Kontext im AddIn bereits ermittelt wurden.
Calling a Sage AppDesigner list from a Sage 100 Microsoft Access AddIn with parameters.
The corresponding AppDesigner list got an attached selection dialogue (Selektionselement) that should not be displayed when called from the Microsoft Access AddIn since the parameters have already been determined in the AddIn context.
"gbOpenAuskunftParameter“
Voraussetzung ist, dass im Access AddIn ein aktueller Wrapper für die Sage Funktion “gbOpenAuskunftParameter“ aus dem Frontend (*.accdb) vorhanden ist.
The prerequisite is that the Access AddIn got a current wrapper for the Sage function "gbOpenAuskunftParameter" from the front end (*.accdb).
Public Function gbOpenAuskunftParameter(ByVal sPartName As String, ByVal sParameterlist As String, Optional bSuppressSelectionDialog As Boolean) As Boolean
gbOpenAuskunftParameter = Eval("gbOpenAuskunftParameter(" & gsStr2Str(sPartName) & "," & _
gsStr2Str(sParameterlist) & "," & _
gsCStr(bSuppressSelectionDialog) & ")")
End FunctionParameter
Damit die Funktion “gbOpenAuskunftParameter“ korrekt funktioniert, muss die von Sage verlangte Parameter-Signatur exakt eingehalten werden.
In order for the "gbOpenAuskunftParameter" function to work correctly, the parameter signature required by Sage must be adhered to exactly.
Dim sAppDesignerPartName As String
Dim sAppDesignerPartParam As String
sAppDesignerPartName = "mdtAddOnsOverviewForAddress.100000000.SAGErpErwDevAddOns"
sAppDesignerPartParam = "Parameter1:=pAddressId; Parameter1Type:=lng; Parameter1Value:=" & gsSAGCStr(lAddressId)
Call gbOpenAuskunftParameter(sAppDesignerPartName, sAppDesignerPartParam, True)Entscheidend ist, dass alle Parameter einzeln in einer String-Liste übergeben werden.
Sind mehr als ein Parameter zu übergeben, dann ist die Semikolon-getrennte Liste entsprechend zu ergänzen und die Nummer im Parameter-Tag zu erhöhen.
Strings bei Parameter-Inhalten müssen unbedingt escaped werden, Sage hat dafür die Funktion “gsStr2Str“ bereitgestellt.
It is crucial that all parameters are passed individually in a string list.
If more than one parameter is to be passed, then the semicolon-separated list must be supplemented accordingly, and the number in the parameter tag increased.
Strings in parameter content must be escaped; Sage has provided the "gsStr2Str" function for this.
sAppDesignerPartParam = "Parameter1:=pAddressId; Parameter1Type:=lng; Parameter1Value:=" & gsCStr(lAddressId) & _
"Parameter2:=pAnotherOne; Parameter2Type:=str; Parameter2Value:=" & gsStr2Str("MyStringContent")Sage Beispiel / Sage example
Ein Beispiel seitens Sage kann aktuell im Frontend “OLAbf.accdb” in der Methode “mShowChargenbestand“ der “frmAbfMainErfassung“ entnommen werden.
An example from Sage can currently be found in the "OLAbf.accdb" frontend in the "mShowChargen Inventory" method of the "frmAbfMainErerfassung".
Sage Parameter
Die Sage Parameter-Typen für o.g. Aufruf sind derzeit wie folgt. Eine aktuelle Liste kann im Frontend-Code nachgeschlagen werden, z.B. in der Funktion “OLAbf.basSysMetadata.gbSetAuskunftParameter“.
Nicht typisierte Parameter werden von Sage im TraceLog als Warnung mit dem Text “Nicht typisierter Parameter:=“ protokolliert.
The Sage parameter types for the above call are currently as follows. An up-to-date list can be looked up in the frontend code, e.g. in the "OLAbf.basSysMetadata.gbSetAuskunftParameter" function.
Any untyped parameters are logged by Sage in the TraceLog as a warning with the text “Nicht typisierter Parameter:=“.
Mögliche Probleme / Possible problems
Auf den ersten Blick sieht man, dass hier alle Probleme bezüglich String-Parsing bei Übergabe aus dem Sage VBA-basierten Frontend zu .net in Frage kommen.
Man muss beachten, dass der Sage-Parser im Laufe der Zeit von Sage immer wieder verändert wurde und teils massive Probleme hat, wenn Sage-”reservierte” Steuerzeichen in Parameterinhalten vorkommen (auch dann, wenn Strings eigentlich korrekt escaped wurden).
Hinzu kommt, dass man nicht vergessen darf, dass gleich auf mehreren Ebenen geparsed werden muss!
So z.B. bereits aus dem VBA-Access-AddIn-Code heraus bei der Übergabe zum Access-basierten Sage-Frontend mit dem VBA”-Eval”-Befehl.
Dann greift das Parsing von Sage im Frontend und dann kommt noch das AppDesigner-/AppServer-basierte Parsing von Sage.
Das alles, bevor die eigentlichen AppDesigner-Elemente aufgerufen werden.
At first glance, you can see that all problems related to string parsing when passing from the Sage VBA-based front end to .net come into question here.
You have to keep in mind that Sage has repeatedly modified the Sage parser over time and sometimes has massive problems if Sage "reserved" control characters appear in parameter contents (even if strings were actually correctly escaped).
In addition, one must remember that occurs on several levels!
For example, already from the VBA Access AddIn code when transferring to the Access-based Sage frontend with the VBA "Eval" command.
After that Sage's parsing happens in the frontend, and then Sage's AppDesigner/AppServer-based parsing comes etc.
All this, before the actual AppDesigner elements are called.
Schlussfolgerung / Conclusion
Es empfiehlt sich ganz klar, keine ”komplexeren” Parameter weiterzugeben, insbesondere keine komplexeren String-Inhalte.
Im Zweifel sollte man “komplexe” Daten vorab selber über die Datenbank serialisieren/zwischenspeichern bzw. sich im Idealfall über einfache Integer-Schlüssel auf Datenbank-Inhalte beziehen und diese dann im .net Quellcode auf Server-Seite auslesen/weiterverarbeiten.
Darüber hinaus gelten die “üblichen Hinweise” bezüglich Nomenklatur im Umgang mit dem AppDesigner.
Beispielsweise ist es eher verwirrend, keine eindeutigen Parameter-Namen zu verwenden und/oder z.B. Parameter-Namen einfach so zu benennen wie Feldnamen etc.
It is highly recommended not to pass along any "rather complex" parameters, especially not any complex string contents.
If in doubt, you should serialize/buffer "complex" data yourself in advance via the database or, ideally, refer to the database contents using simple integer keys and then read/process them in the .net source code on the server side.
In addition, the "usual notes" regarding nomenclature when using the AppDesigner apply.
For example, it can be rather confusing not to use unique parameter names and/or to name parameters like the field names etc.
Schlecht/bad:
Artikelnummer:=[Artikelnummer]Besser/better:
pArtikelNr:=[Artikelnummer]
