• Thomas Pollinger
• 10.06.2019
• DE

PreExecute: Tuning Tipps und Tricks

In den letzten drei Artikeln wurden die unterschiedlichen Möglichkeiten für RDExecute und PreExecute erläutert. Ebenso wie man es einrichtet und auf was man achten sollte. Jetzt möchte ich nochmals die wichtigsten Schritte zusammenfassen und auf weitere Artikel bzw. hilfreiche Tipps/Tricks hinweisen.
 

Frameworksprache

Man sollte sich immer Gedanken zu der verwendeten Sprache vorher machen. Klar kann man PHP, Java, ASP.NET, sprich alles was der IIS unterstützt, verwenden. Jedoch macht das dann auch direkt immer Sinn. Je mehr unterschiedliche Dinge man zusammenbringt, destogrößer sind später die Anhängigkeiten.

Daher meine Empfehlung: Verwendet eine Management Server nahe Sprache, wie C# oder VBScript. Dies macht die Konfiguration und spätere Integration etwas leichter.
 

Einrichtung und Konfiguration

Auch sollte man sich gut überlegen wofür man RDExecute und PreExecute verwendet. Denn danach richtet sich auch die Konfiguration innerhalb des Management Servers, aber auch im IIS. Dazu gibt es Dinge zu beachten wie:

• Verwendte Frameworksprache
• Applikationspool-Einstellungen
• Projektkonfiguration im Management Server
• Zugriffe und Rechte auf Module bzw. Schnittstellen

Dazu kommen noch folgenden Fragen:

• Handelt es sich um eine Management Server Cluster oder Einzel-Installation?
• Sollte Caching auf Development und Produktion abweichen?
• Spielt ein Datenbank-Zugriff eine Rolle oder nicht?
• Wird es nur für SmartEdit oder auch für die Publizierung verwendet?
• Benötige ich PreExecute wirklich oder kann es z.B. auch ein Delivery Server für mich erledigen?

Daher meine Empfehlung: Macht ein Konzept, definiert die EInsatzgebiete und richtet danach das System entsprechend ein. Wichtig ist hierbei, eine sehr gute Dokumentation. ;)
 

Verwendung und Möglichkeiten

Beim Einsatz von PreExecute sollte man auch die Eigenarten des Systems kennen. Dazu gehören Abfolgen, Laufzeit und Infrastruktur. Daher habe ich mal die nachfolgenden Hinweise aufgelistet:

• Rendering-Reihenfolge (=> Die RedDot-Reihenfolge)
• Caching, Templateaufbau und Einsatz (=> C# im PreExecute: Tipps, Tricks und böse Fallen)
• Wartung und Performance (=> PreExecute: Temporary .NET Cache Files, Simply RedDot: "Slow CMS Due to .NET Preexecution")
• RQL notwendig (=> rdb: RQL in a nutshell, rdb: RedDot CMS API – or – RQL in a nutshell – Part 2)
• Debugging (=> rdb: Debugging PreExecute ASP – Reloaded)
• Vorhandene Beispiele (=> OpenText™ Web Site Management Xample Project 16.0.3)

Da es sich um eine Erweiterung per Programmiersprache handelt, sind hier nahezu keine Grenzen gesetzt. Jedoch sollte man es auch nicht übertreiben und diese Möglichkeit immer sinngemäß einsetzen.

Im Zusammenspiel mit dem s.g. .NET-Ordner bekommt man direkt weitere Möglichkeiten geboten, die man sich auch vorher ansehen sollte. Denn wie schon im Artikel PreExecute: RD- & PreExecute: Verwendung und Einstellungen im Abschnitt .NET Ordner verwenden beschrieben. Lassen sich auch komplette ASP.NET Applikationen über den Management Server zusammen mit redaktionellen Inhalten ausspielen. ;)
 

Weitere Artikel mit wichtigen Infos

• OpenText™ | RDExecute & PreExecute
• PreExecute: RD- & PreExecute: Verwendung und Einstellungen
• PreExecute: Eigener AppPool
• PreExecute: Temporary .NET Cache Files
• C# im PreExecute: Tipps, Tricks und böse Fallen
• Die RedDot-Reihenfolge
• OpenText™ Web Site Management Xample Project 16.0.3
• rdb: How to manage Quotes, Placeholders and Pre-Execute using VBScript within RedDot CMS
• rdb: Debugging PreExecute ASP – Reloaded
• und zusätzlich die Online-Hilfe mit den Suchbegriffen "RDExecute" und/oder "PreExecute".

Über den Autor: