• Die Blackbox

      The Blackbox

      Die Blackbox

    • Im Zuge der Entwicklung eines CRM-Systems für eines der größten schweizerischen Telekommunikationsunternehmen gerieten wir an das Problem, dass das eingesetzte CRM-System kaum Anpassungen am User Interface ermöglichte. Lediglich durch JavaScript Makros konnten Felder ein- bzw. ausgeblendet werden. Diese Makros sind auf 4000 Zeichen begrenzt und konnten lediglich im CRM editiert werden. Eine Versionierung dieser Makros stand nicht zur Verfügung.

      Durch die Nutzung eines Repository und durch die Einführung eines entsprechenden Entwicklungsprozesses konnten diese Makros nun versioniert und verwaltet werden.

      Parallel hierzu solle die Möglichkeit der Einbindung von verschiedenster JavaScript-Frameworks wie beispielsweise jQuery u.Ä. gebietet werden. Laut CRM-Hersteller befinde sich eine solche Funktionalität in Entwicklung, jedoch ist die Verfügbarkeit erst in einem der kommenden Releases geplant.

      Mit Hilfe von Frameworks kann die Länge der Makros reduziert werden, da diese Frameworks durch die Abstraktion kürzeren Code ermöglichen, welches sich wiederum Positiv im Hinblick auf die Zeichelängenbegrenzung der Makros auswirkten würde. Zunächst wurde überlegt den Framework-Code selbst in die Makros einzubinden. Problematisch ist dabei, dass die Frameworks meist weitaus mehr als 4000 Zeichen Code bestehen. Eine Zerstückelung des Framework in 4000-Zeichen-Chunks war schlichtweg unhandlich und nicht vertretbar.

      Somit musste nach einer alternativen Lösung gesucht werden. Die Einbindung direkt über script-Tags innerhalb der Makros war ebenfalls nicht möglich. Durch einen kleinen Hack konnten externe Frameworks per asynchronem Aufruf direkt in den head-Tag des HTML-Dokumentes geladen werden. Die Entwicklung der Makros wurde somit vereinfacht und verschnellert. Zudem wurde eine höhere Cross-Browser Kompatibilität garantiert.

      Zusätzlich ermöglichten die Makros selbst Platzhalter für CRM-spezifische Variablen, wie User-ID oder User-Aliase, die in den von uns asynchron nachgeladenen Skripten nicht zur Verfügung standen. Hier musste ebenfalls ein Mechanismus entwickelt werden, der die entsprechenden Variablen abgreift und für die nachgeladenen Skripte zur Verfügung stellt.

      Im Zuge der Entwicklung eines CRM-Systems für eines der größten schweizerischen Telekommunikationsunternehmen gerieten wir an das Problem, dass das eingesetzte CRM-System kaum Anpassungen am User Interface ermöglichte. Lediglich durch JavaScript Makros konnten Felder ein- bzw. ausgeblendet werden. Diese Makros sind auf 4000 Zeichen begrenzt und konnten lediglich im CRM editiert werden. Eine Versionierung dieser Makros stand nicht zur Verfügung.

      Durch die Nutzung eines Repository und durch die Einführung eines entsprechenden Entwicklungsprozesses konnten diese Makros nun versioniert und verwaltet werden.

      Parallel hierzu solle die Möglichkeit der Einbindung von verschiedenster JavaScript-Frameworks wie beispielsweise jQuery u.Ä. gebietet werden. Laut CRM-Hersteller befinde sich eine solche Funktionalität in Entwicklung, jedoch ist die Verfügbarkeit erst in einem der kommenden Releases geplant.

      Mit Hilfe von Frameworks kann die Länge der Makros reduziert werden, da diese Frameworks durch die Abstraktion kürzeren Code ermöglichen, welches sich wiederum Positiv im Hinblick auf die Zeichelängenbegrenzung der Makros auswirkten würde. Zunächst wurde überlegt den Framework-Code selbst in die Makros einzubinden. Problematisch ist dabei, dass die Frameworks meist weitaus mehr als 4000 Zeichen Code bestehen. Eine Zerstückelung des Framework in 4000-Zeichen-Chunks war schlichtweg unhandlich und nicht vertretbar.

      Somit musste nach einer alternativen Lösung gesucht werden. Die Einbindung direkt über script-Tags innerhalb der Makros war ebenfalls nicht möglich. Durch einen kleinen Hack konnten externe Frameworks per asynchronem Aufruf direkt in den head-Tag des HTML-Dokumentes geladen werden. Die Entwicklung der Makros wurde somit vereinfacht und verschnellert. Zudem wurde eine höhere Cross-Browser Kompatibilität garantiert.

      Zusätzlich ermöglichten die Makros selbst Platzhalter für CRM-spezifische Variablen, wie User-ID oder User-Aliase, die in den von uns asynchron nachgeladenen Skripten nicht zur Verfügung standen. Hier musste ebenfalls ein Mechanismus entwickelt werden, der die entsprechenden Variablen abgreift und für die nachgeladenen Skripte zur Verfügung stellt.

      During the development of an CRM-System for one of the biggest telecommunication companys of the Swizerland, we couldn't make all adaption at the user interface because of the used CRM-System (so-called Blackbox). We could show or hide fields only by JavaScript macros. These macros were limited in space (4000 signs) and it was just allowed to edit them in the CMR. A versioning of the macros wasn't available.

      Because of the usage of a repository the macros and the introduction of an appropriate development process it was possible to versioning and to manage the macros.

      In parallel, it should be possible to integrate different Java-Script-Frameworks e.g.jQuery. The CRM-producer developed such a functionality but it was not released at that moment.

      We could additionally reduce the length of the macros by using frameworks because of the abstraction of theses which allows to shorten the code. This has also a positive influence due to the limitation of the macros-length. The first thought was to integrate the framework-code into the macros. A problem was that the code insist more than 4000 sights. We did'nt want to cut the code into 4000-sights-chunks because that solution was unhandy.

      So we searched for an alternative solution. It was not possible to integrate the macros with script-tags. Finally, we could load external frameworks (because of a little hack) into the head-tag of the HTML-document by an asynchronous call. The development of the macros get easier and faster. Furthermore, a higher cross-browser compatibility were guaranteed.

      In addition the macros enable placeholder for CRM-specific variable e.g. user-ID/ User-aliase which weren't available in the asynchronous script which were reloaded by us. Now then we had to develop a mechanism which takes the variable and supply it for the reloaded scips. Because of our long pedigree experience with webtechnologies it was possible to use the macros now without waiting for months or even years. Our customer could also work more efficient.