Ablösung der XML Dateien (SAP Jobketten im Redwood) und Implementierung im Ticketsystem

[Wolkenfrei]

Guten Tag und ein Frohes neues Jahr zusammen.

Da ich diesen Sommer meine Abschlussprüfung habe und ich ein Projekt benötige, habe ich mir folgendes Thema ausgesucht

Ablösung der XML Dateien (SAP Jobketten im Redwood) und Implementierung im iET Workcenter

Es wird täglich eine XML Datei aus dem Redwood erstellt und auf einem Laufwerk gespeichert. Da XML aber eher eine "unsichere" Datei ist, möchte ich gerne, dass ich diese Datei automatisiert umwandele und in unser Ticketsystem einspiele. Unser Ticketsystem wird für alle genutzt (Ticket erstellung, Berechtigungen werden für einzelen User vergeben, Knowledge Base ... u.s.w).

Die SAP Jobs ,die stündlich, täglich oder auch nur einmal im Jahr laufen, werden bei uns im Redwood (SAP Business Process Automation by Redwood) angezeigt und kann von uns gesteuert werden (starten, anhalten etc).

Ich möchte gerne, dass diese Übersicht im Ticketsystem angezeigt wird, da fast jeder mit dem Ticketsystem arbeitet und somit nicht immer der Browser geöffnet werden muss um das Redwood zu öffnen.

Die Vermutung liegt nahe, dass das ein Thema ist, wo man viel Programmieren muss.

Ist sowas als Fachinformatiker Systemintegration realisierbar ?

Viele Grüße

[Alistair]

Als Fisi kann man zwar im Abschlussprojekt durchaus auch was programmieren. Das sollte aber nicht den Hauptteil ausmachen. Das klingt mir hier aber wie du ja selbst schon feststellst etwas AE lastig.

[Gast Arvi]

Hört sich tatsächlich eher nach einem Projekt für Anwendungsentwickler an. Wirtschaftlich bleibt da auch nur eine Amortisationsrechnung übrig - abgesehen davon daß es sicherlich nicht einfach ist plausibel darzulegen wie viel Kosten durch den Wegfall der Browser Öffnung eingespart werden können finde ich eine Amortisationsrechnung allein auf Arbeitsstunden für einen FISI Projekt etwas Mau, da auch die Wirtschaftliche Entscheidung entfällt.

Mein Gefühl sagt mir, dass du mit einem anderen Projekt besser fährst.

Bearbeitet 4. Januar 2018 von Arvi

[Wolkenfrei]

vor 42 Minuten schrieb Arvi:

Mein Gefühl sagt mir, dass du mit einem anderen Projekt besser fährst.

Vielen lieben Dank für die schnellen Antworten, damit habe ich nicht gerechnet :-)

Es ist nich so leicht ein anderes Projekt zu finden. Seit meiner Ausbildung bin ich für das Ticketsystem zuständig und erweitere es auch.

Änderungen werden auf der Datenbank erledigt - ich mag das.

Da die Geräte in unser Firma schon über das Ticketsystem gesteuert und gewartet werden, fällt mir da nicht mehr soviel ein.

[Rienne]

vor 3 Minuten schrieb Wolkenfrei:

Da die Geräte in unser Firma schon über das Ticketsystem gesteuert und gewartet werden, fällt mir da nicht mehr soviel ein.

Dann solltest du dich vielleicht einmal mit deinem Ausbilder zusammen setzen. Dem sollten doch sicherlich ein paar Themen einfallen, die bei euch umzusetzen sind und in den Rahmen einer FISI-Abschlussprüfung passen.

[Wolkenfrei]

Gerade eben schrieb Rienne:

Dann solltest du dich vielleicht einmal mit deinem Ausbilder zusammen setzen. Dem sollten doch sicherlich ein paar Themen einfallen, die bei euch umzusetzen sind und in den Rahmen einer FISI-Abschlussprüfung passen.

Das habe ich bereits gemacht.

Mein Wunsch war es etwas mit SQL zu machen, darauf hin war das Thema die Ablösung von XML und implementierung in das Ticketsystem.
Ich muss gestehen, dass ich nicht so gut bin in SQL, mag das Thema aber wirklich sehr.

Mein Kollege hat 2013 die Hardware im Ticketsystem implementiert (Projektarbeit) und musste sich von dem Prüfungsausschuss richtig auseinander nehmen lassen. Da der Prüfungsausschuss nicht soviel über die Programme etc wussten, haben Sie ihn Sachen gefragt, die nicht gerade einfach zu beantworten waren und er vielleicht auch nicht damit gerechnet hat... Kann passieren.

Ich möchte das allerdings nicht so haben, ich möchte ein Super Thema, wo mich die Prüfer zu meinem Projekt prüfen können.

[Wolkenfrei]

Guten Morgen,

nach Rücksprache mit dem Ausbilder hat sich rausgestellt, dass es sich bei dem Projekt wirklich um eine XML Datei handelt, die umgewandelt wird, so dass SQL die Daten lesen kann. Sobald die Daten in SWL hinterlegt sind, werden diese in das Ticketsystem implementiert.

Das Projekt soll die Anwendungsentwickler entlassten. Sollte es Fehler in einer Jobkette geben oder der tägliche Job ist nicht gelaufen, kann man im Ticketsystem über ein drop down Menü sehen, wo sich dieser Fehler in welchem Step befindet. Kurz gesagt: Die Übersicht ist einfacher und ersparrt den Anwendungsentwickler viel Zeit.

Meine Aufgabe wäre es, die XML automatisiert umzuwandeln, so dass es SQL lesen kann (eigene kleine SQL Querie schreiben) und damit die Daten in das Tickettool implementiert werden können.

Laut meinem Ausbilder ist das Thema nicht so AEW lästig, hat aber viel mit der Datenbank und der Ticketoberfläche zu tun - Ist das trotzdem noch Anwendungsenwickerl Thema ?

Viele Grüße

[Alistair]

Ich kenn euer Ticketsystem nicht aber für mich hört sich das ehrlich gesagt trotzdem etwas komisch an. Wenn der Programmierteil so klein sein soll wie dein Ausbilder sagt, dann seh ich die fachliche Tiefe nicht. Alles was du scheinbar ja machst ist die Umwandlung zu schreiben. Das ist AE. Was anderes scheinst du ja nicht zu machen ...

[Whiz-zarD]

Theoretisch bräuchte man sowas gar nicht programmieren. Da gibt es Haufenweise ETL-Tools, die dies übernehmen könnten. Gut man müsste dann schauen, ob es für diese Tools Konnektoren für die Eingangsquelle (SAP?) gibt. Viel mit Datenbank hat das Projekt auch nicht zu tun. Die Tabellen werden ja schon vom Ticketsystem vorgegeben und müssen nicht selbst entworfen werden.

Anstatt aber reine SQL-Queries abzufeuern würde ich mal schauen, ob das Ticketsystem eine API besitzt, mit der man von Außen Tickets generieren kann. Das ist der sichere Weg, da man nicht sicher sein kann, ob da nicht noch andere Routinen, während der Ticketerstellung, laufen, wie z.B. eine Generierung von Metadaten. So könnte man die XML-Datei einlesen und dann die API aufrufen. 

Allerdings sehe ich da auch Probleme mit der fachlichen Tiefe. Aus einer XML-Datei SQL-Insert-Queries zu bauen, ist im Grunde nur noch Fleißarbeit. 

vor 3 Stunden schrieb Wolkenfrei:

Das Projekt soll die Anwendungsentwickler entlassten. Sollte es Fehler in einer Jobkette geben oder der tägliche Job ist nicht gelaufen, kann man im Ticketsystem über ein drop down Menü sehen, wo sich dieser Fehler in welchem Step befindet. Kurz gesagt: Die Übersicht ist einfacher und ersparrt den Anwendungsentwickler viel Zeit.

Ihr dürft aber nicht vergessen, wenn ihr reine SQL-Queries abfeuert, umgeht ihr das Ticketsystem, weil dies davon nichts mitbekommt. Wenn, dann müsst ihr diese Fehler auch noch ins Ticketsystem übertragen und dann wird das Thema auf einmal sehr komplex. Darum sagte ich ja, dass ihr lieber mal schauen solltet, ob das Ticketsystem nicht eine API besitzt. Wir haben auch so tolle Kunden, die meinen, Daten per SQL-Queries in die Datenbank zu pumpen, anstatt unsere Import-Funktion zu verwenden. Wir nehmen da keinerlei Haftung, wenn da irgendwas schieflaufen sollte und es läuft da regelmäßig was schief.

[Wolkenfrei]

vor 4 Minuten schrieb Whiz-zarD:

Ihr dürft aber nicht vergessen, wenn ihr reine SQL-Queries abfeuert, umgeht ihr das Ticketsystem, weil dies davon nichts mitbekommt. Wenn, dann müsst ihr diese Fehler auch noch ins Ticketsystem übertragen und dann wird das Thema auf einmal sehr komplex. Darum sagte ich ja, dass ihr lieber mal schauen solltet, ob das Ticketsystem nicht eine API besitzt. Wir haben auch so tolle Kunden, die meinen, Daten per SQL-Queries in die Datenbank zu pumpen, anstatt unsere Import-Funktion zu verwenden. Wir nehmen da keinerlei Haftung, wenn da irgendwas schieflaufen sollte und es läuft da regelmäßig was schief.

Vielen Dank für die info, dass muss und werde ich nochmal mit dem Abteilungsleiter besprechen. Diese Sicht habe ich noch nicht bedacht.

Ich habe meinem Abteilungsleiter gesagt, dass ich auf jeden Fall etwas mit SQL machen möchte.