PDF Formular

Re: PDF Formular

Meines Wissens gibt es für SAP "Adobe Interactive Forms". Das ist aber ein kostenpflichtiges Addon, bei dem Adobe die Hand aufhält, weswegen SAP davon auch schon wieder abgerückt sein soll und stattdessen die (kostenlosen) Smartforms präferiert.

Re: PDF Formular

Woraus schließt du das? Mir ist sowas nicht bekannt.

Das hat mir ein Kollege mal erzählt. Einst war es Sapscript, dann kamen Smartforms, dann SAP Interactive Forms for Adobe, die Smartforms insofern ersetzen konnten, als ihr nicht-interaktiver Teil (und nur dieser) lizenzkostenfrei war, von denen man sich dann wieder distanziert haben und Smartforms wieder voll in Amt und Würden eingesetzt haben soll.

Gerade Adobe PDF Forms wurde übrigens nicht hart verdrahtet, sondern es gibt eine ordentliche Schnittstelle

Und Schnittstellen sind immer fehleranfälliger und schwieriger in der Handhabung als eine perfekte nahtlose Integration, wie Smartforms sie bieten. Obendrein braucht man dafür einen zusätzlichen Adobe-Server, der zumindest von der Hardware her auch Geld kostet und Schwierigkeiten verursachen kann, wenn die Kommunikation zum SAP-Server stockt (und sei es aus Netzwerkgründen).

Bei uns ist im Bereich von Processes&Forms der Adobe LiveCycle Designer im Einsatz, den SAP ja auch "integriert" hat. IMHO ein fürchterliches Werkzeug. Du designst aufwendig eine halbe Stunde, und wenn Du Deine Arbeit dann sichern willst, bekommst Du eine Fehlermeldung, die Dich darauf hinweist, dass Du nicht aufgepasst hast und die ganze Zeit im Anzeigemodus warst und Deine Arbeit daher für die Katz ist. Das ist wie wenn der Dynpro Editor im Anzeigemodus alle Felder eingabebereit hätte, so dass Du Dein Dynpro zusammenstellen, Felder anlegen usw. kannst und erst beim Sichern auf die Nase fällst. Der LiveCycle Designer hat mehrere Major Releases durchlaufen, aber dieser offensichtliche Mist ist nie geändert worden, was mich zu der Vermutung inspiriert, dass es ein Problem mit der SAP-Integration desselben, mit anderen Worten, mit der Schnittstelle sein könnte.

Wie dem auch sein mag, ob die SAP sich tatsächlich von Adobe Interactive Forms distanziert hat, kann ich nicht belegen und bin jetzt auch zu faul zu recherchieren. Ich habe nur wiedergegeben, was ich von Kollegen gehört hatte, die sich mit dem Thema beschäftigt haben. Die Information ist auch schon ein paar Jahre alt. Kannst ja mal Horst Keller fragen.

Re: PDF Formular

Ralf hat geschrieben:Ah, ok. Hörensagen. Ich dachte du schreibst hier von irgendwie nachprüfbaren Fakten oder wenigstens von Indizien (ich kenne wen bei der SAP, der hat gesagt....).

Den zweiten Halbsatz hast Du sicherlich hinzugefügt, um Deine gebetsmühlenartigen Verweise auf Horst Keller zu retten...

Auf sowas antworte ich immer mit dem sich selbst beweisenden Satz: Und alle Pauschalisierungen sind falsch.

Nettes Paradoxon; gefällt mir.

Ich könnte dir uralten, hochintegrierten Kram von der SAP zeigen, der Murks hoch drei ist. Sowas wie die Anweisung MESSAGE zum Beispiel. Aber das zu diskutieren würde hier zu weit gehen, hab ich aber neulich auf dem SITHH mal andiskutiert. MESSAGE funktioniert nämlich nur richtig gut mit einer SAPGUI dahinter. Schon wenn man ein Java-Portal hat...

Ein zweites Paradoxon, und diesmal vermutlich nicht beabsichtigt. Hoch integrierte Funktionalitäten sind abzulehnen, weil sie die Vorzüge ihrer hohen Integration bei nicht integrierten, per Schnittstelle angebundenen Funktionalitäten nicht ausspielen können? Der war ein guter!

Auch zu Java ist die SAP ja mittlerweile wieder auf Abstand gegangen, und diesmal bin ich mir sicher, weil wir den Kram im Haus haben bzw. hatten. Früher lief das ESS-Portal auf einem per Schnittstelle angebundenen Java-Server, mittlerweile ist Java raus, und das Portal läuft direkt auf dem Applikationsserver. Diese Umstellung hat uns die Arbeit damit deutlich erleichtert. Dafür ist freilich mit Fiori neuer Stress ins Haus gekommen, denn das läuft wieder auf einem getrennten Server... das zieht sich bis ins Berechtigungssystem hinein, wo sich bei Fiori "Berechtigungen" allein dadurch ergeben, dass etwas im Menü der Rolle steht, obgleich gar keine Berechtigungsobjekte dahinterstehen. Damit ist das ganze Konzept des SAP-Berechtigungskonzeptes durchbrochen.

Re: PDF Formular

Integration lebt davon, dass es keine Alternativen gibt und man auf seiner Insel bleibt. Und das ist nunmal lebensfremd.

SAP war schon immer ein Meister darin, externe Schnittstellen anzubinden, jedenfalls wenn man mit ABAP umgehen konnte (und zum Teil auch ohne, etwa per LSMW). Mit wievielen Systemen habe ich schon Daten austauschen müssen, deren Flexibilität hinsichtlich der Schnittstelle minimal war, und stets war ich als SAP-ler gefordert, mich daran anzupassen und die Datenübertragung hinzukriegen, und es war immer möglich!

Das heißt aber nicht, dass Schnittstellen wünschenswert sind. Sie sind ein notwendiges Übel, und jede Schnittstelle, die bauen und pflegen zu müssen man vermeiden kann, ist ein Gewinn. Schnittstellen sollten also nur dort verwendet werden, wo es sich nicht zu vertretbaren Konditionen vermeiden lässt.

Das funktioniert, wenn SAP alles kann und zwar besser als alle anderen. Wenn ich interaktive Formulare brauche, stehe ich da wie blöd.

Ja, aber vielen reichen eben nicht interaktive Formulare. Auch für diese hat die SAP ja Adobe Forms anstelle von Smartforms empfohlen nach der Devise "Twix ist das neue Raider" unter Verweis darauf, dass Adobe Forms bei nicht-interaktiver Nutzung lizenzkostenfrei ist. Das aber ist ein typisches Beispiel dafür, wie man sich unnötige Schnittstellen (nebst unnötiger Hardware) und den damit verbundenen Stress einhandelt. Da sind Smartforms tausendmal besser!

Braucht man tatsächlich interaktive Formulare, dann haben die Adobe Forms ihre durch Anforderungen gedeckte Daseinsberechtigung, auch wenn es natürlich schön gewesen wäre, wenn die SAP die Smartforms entsprechend ausgebaut hätte.

Aber die Kunden nicht. Ich kenne viele Java-Portale, die sich des SAP bedienen. Da kannst du dann deine tolle Integration das Klo runterspülen.

Du willst die bessere Lösung das Klo runterspülen, bloß weil es viele Kunden gibt, die sie nicht nutzen? Zu denen würde ich sagen, selber Schuld.

Wenn du mal mit Amazon zusammengearbeitet hast, wirst du feststellen, dass die sich nicht als "Versandhaus" verstehen, sondern als Technologiekonzern, für den das Versandunternehmen nur ein Anwendungsbeispiel für ihre Technologie ist. In diese Richtung wandelt sich die SAP auch zusehens, wenn man sich anschaut, wohin die Reise bei denen geht.

Bei SAP ist das schon immer die Richtung gewesen, seit sie sich von ihren FI-Wurzeln gelöst haben. Natürlich ist es richtig und wichtig, so viele externe Lösungen wie möglich anbinden zu können, und wie gesagt, an der Stelle ist die SAP schon immer vorne mit dabei gewesen. Das heißt aber nicht, dass man sich im konkreten Anwendungsfall darum reißen sollte, eine neue Schnittstelle zu bauen, wenn es sich vermeiden lässt. Integriert ist immer besser, aber es ist klar, dass man nicht alles integrieren kann. Gerade weil integriert immer besser ist, hat SAP als eierlegende Wollmilchsau ja seine Daseinsberechtigung. Wäre Integration egal, könnte man FI mit irgendeiner KHK-Fibusoftware machen (ich weiß, ist übertrieben), MM mit einer Lagerhaltungssoftware, kombiniert mit einer Bestellsoftware für den Nachschub, SD mit einem Vertriebssystem usw. und die ganzen Systeme dann über Schnittstellen miteinander vernetzen. Dabei wünsche ich viel Spaß und gute Unterhaltung!

Wenn man sich aber den Riesenschritt von Sapscript zu Smartforms anschaut, dann ist schon beeindruckend, was da integriert worden ist, und ich glaube, eine Integretion interaktiver Dokumente wäre auch noch möglich und in dem Falle auch sinnvoll gewesen, denn interaktive Dokumente sind vielseitig genug, um modulübergreifend Anwendungsmöglichkeiten zu finden.