none
Datenabzug SAP R/3 mit dem BizTalk Server

    Frage

  • Hallo Forum,

    ich beschäftige mich derzeit mit der Integration des Biztalk Servers 2006 R2 in eine bestehende Unternehmenslandschaft, welche neben einem SAP R/3 auch Applikationen aus dem Bereich BI enthält. Hierzu ist es wichtig, Daten aus unterschiedlichen SAP Modulen (SD, FI, CO) in eine Staging-Datenbank im MS SQL Server 2008 zu laden.

    Hierzu habe ich einige Fragen: Die generelle Möglichkeit eines Datenabzugs wird ja sicherlich vermittels des BizTalk Adapters für SAP gegeben sein. Kann ich mit dem BizTalk auch auf Änderungen im SAP "lauschen", sprich Datenimporte in den SQL Server in dem Moment durchführen, sobald sich Buchungen, Stammdatensatzänderungen oder ähnliches ereignen?

    Generell würde mich hier interessieren, wie so etwas optimal umzusetzen ist.

    Vielen Dank schon mal.

    Holger Teichmann

    Dienstag, 20. April 2010 12:12

Antworten

  • Hallo,

    mit dem BizTalk Adapter Pack 2.0 ist es möglich direkt einen 'SELECT' auf SAP Tabellen zu machen. Das BizTalk Adapter Pack 2.0 kann mit BizTalk, SSIS, SharePoint und aus .NET Applikationen verwendet werden. Generell würde ich davon abraten mit BizTalk ETL Szenarien zu machen, da der BTS durch seine Architektur nicht dafür geeignet ist und dieses Szenario schaut mir sehr nach ETL aus was dann mit SSIS zu lösen wäre. Ich verwende oft eine Kombination von BizTalk, SSIS und dem BizTalk Adapter Pack 2.0. Wenn die Änderungen im SAP mittels Idoc z.B. durch Auswertung der Änderungszeiger kommen, dann ist natürlich BTS für diesen Teil vorzuziehen, da so die Idoc's am besten gemapped werden können.

    Wenn ich mehr Details kenne könnte ich gerne einen Architekturvorschlag machen ...

    Grüße

    Andreas Winterer

    Dienstag, 20. April 2010 17:36

Alle Antworten

  • Hallo Holger,

    grundsätzlich ist mir der BizTalk Server wichtig (ich verdiene meine Brötchen damit). Wenn ich deine Requirements lese würde ich aber spontan auf den Einsatz des BizTalks verzichten, da alles mit den bordeigenen Mitteln des SQL Servers realisierbar ist (Featurepack für SQL Server 2008). Hast Du den Bedarf für Transformationen, Mappings oder ähnliches von Daten, teil uns das bitte mit. Ich könnte Dir dann entsprechende Tipps geben.

    Schöne Grüße

    Oliver

    Dienstag, 20. April 2010 12:57
  • Hallo Oliver,

    nun ist aber zum einen der Biztalk bereits vorhanden (wird jedoch derzeit kaum benutzt) und zum anderen ist es uns wichtig, Daten ereignisgesteuert (von SAP Seite) abzuziehen.

    Bisher habe ich die Datenabzüge über den .NET Data Provider for mySAP Business Suite realisiert, allerdings würde ich tatsächlich gerne den Biztalk nutzen, da beispielsweise der Data Provider unter Windows Server 2008 nicht lauffähig ist und ich die Daten nur jobgesteuert abziehen kann.

    Zudem könnte ich mit dem BT auf fehlerhafte Datenabzüge sicherlich etwas differenzierter reagieren.

    Die Sache mit den Transformationen und Mappings wären darüber hinaus natürlich ein nice-to-have.

    Beste Grüße

    Holger

     

    Dienstag, 20. April 2010 13:23
  • Hallo,
     
    Die skizzierte Variante des "Lauschens" lässt sich meines Wissens nach nicht direkt umsetzen, da hier Funktionalitäten seitens SAP fehlen. Wäre es praktikabel, ggf. entsprechend den Änderungen seitens SAP entsprechende IDOCs erzeugen zu lassen, um diese dann direkt an den BizTalk weiterzuleiten?
     
    Das wäre eigentlich eine übliche Variante.

    Grüße
     
    Jörg Fischer
     
    "Holger Teichmann" schrieb im Newsbeitrag news:b0ec7ae6-ed6f-4b63-9962-0e209b32788e...

    Hallo Oliver,

    nun ist aber zum einen der Biztalk bereits vorhanden (wird jedoch derzeit kaum benutzt) und zum anderen ist es uns wichtig, Daten ereignisgesteuert (von SAP Seite) abzuziehen.

    Bisher habe ich die Datenabzüge über den .NET Data Provider for mySAP Business Suite realisiert, allerdings würde ich tatsächlich gerne den Biztalk nutzen, da beispielsweise der Data Provider unter Windows Server 2008 nicht lauffähig ist und ich die Daten nur jobgesteuert abziehen kann.

    Zudem könnte ich mit dem BT auf fehlerhafte Datenabzüge sicherlich etwas differenzierter reagieren.

    Die Sache mit den Transformationen und Mappings wären darüber hinaus natürlich ein nice-to-have.

    Beste Grüße

    Holger

     


    Jörg Fischer
    Dienstag, 20. April 2010 13:29
    Moderator
  • Hallo,

    generell halte ich die Verwendung von Idocs für diese Art von Datenabzug als zu überladen. Allerdings könnte ich mir vorstellen, dass wenn SAP die Nachbuchungen des Tages abschliesst, dieses via einem einzelnen Idoc Richtung BT kundtut.

    Hierauf könnte man dann ja den BT dazu animieren, die entsprechenden Tabellendaten des SAP abzuziehen.

     

    Nochmal die Frage: Der Biztalk ist doch in der Lage direkt auf die Tabellen des SAP zuzugreifen, ähnlich dem .NET Data Provider?

    Gruß, Holger Teichmann

     

     

    Dienstag, 20. April 2010 15:00
  • Hallo,

    mit dem BizTalk Adapter Pack 2.0 ist es möglich direkt einen 'SELECT' auf SAP Tabellen zu machen. Das BizTalk Adapter Pack 2.0 kann mit BizTalk, SSIS, SharePoint und aus .NET Applikationen verwendet werden. Generell würde ich davon abraten mit BizTalk ETL Szenarien zu machen, da der BTS durch seine Architektur nicht dafür geeignet ist und dieses Szenario schaut mir sehr nach ETL aus was dann mit SSIS zu lösen wäre. Ich verwende oft eine Kombination von BizTalk, SSIS und dem BizTalk Adapter Pack 2.0. Wenn die Änderungen im SAP mittels Idoc z.B. durch Auswertung der Änderungszeiger kommen, dann ist natürlich BTS für diesen Teil vorzuziehen, da so die Idoc's am besten gemapped werden können.

    Wenn ich mehr Details kenne könnte ich gerne einen Architekturvorschlag machen ...

    Grüße

    Andreas Winterer

    Dienstag, 20. April 2010 17:36
  • Guten Morgen,

    ja, der BTS wäre in meinem angedachten Szenario in der Tat Bestandteil eines ETL Prozesses. Mir geht es prinzipiell darum, die derzeitige Lösung, bei der die Daten jobgesteuert via SSIS Paket zu einem bestimmten Zeitpunkt geholt werden, abzulösen und einen ereignisgesteuerten Import zu etablieren.

    Natürlich ist die Idee dabei, wenn möglich, den BTS als zentrale "Datenschleuder" zu verwenden und hier auch die nötigen Mappings und Business Logiken zu hinterlegen. Der SQL Server 2008 sollte dann nur noch als reiner Datenspeicher agieren.

    Insofern finde ich den Vorschlag der Kombination von BizTalk, SSIS und dem BizTalk Adapter Pack 2.0 interessant.

    Beste Grüße,

    Holger Teichmann


    Mittwoch, 21. April 2010 08:18
  • Hallo,

    Grundsätzlich kannst auf SAP Events lauschen. Hierzu musst du grundsätzlich des BizTalk über RFC als "Inbound" Device registrieren (Listener Location mit angeben). Wenn hierzu Fragen sind gerne gesondert, ansonsten überspringe ich das mal hier.

    1. Anfrage von IDOCS mit Änderungszeiger

    Wenn SAP Änderungszeiger für das Businessobjekt anbietet, könnt ihr hierdurch bei Änderung / Neuanlage ein IDOC genieren lassen und dies an den BizTalk Server senden.

     

    2. BAdI / Userexit und Call Function

    Einen leeren Dummy-Funktionsbaustein erstellen, der genau die Daten übergibt, die im BizTalk benötigt werden (Importing oder Tables Parameter). Diesen dann im Visual Studio als Inbound RFC einlesen und ein Schema generieren. Im SAP Funktionsbaustein diesen sich selbst aufrufen lassen, aber mit DESTINATION "MeineBizTalkLocation".

     

    3. Workflow

    Bei einigen Business Objekten werden SAP Business Workflows angestoßen. Hier einen Dummy-Workflow mit einem Schritt der ähnlich in bei Lösung 2 einen Dummy-Funktionsbaustein aufruft.

     

    Bei allen drei Lösungen wird direkt eine Orchestation / ein Routing im BizTalk angestoßen und du kannst die Daten nahezu in Echtzeit in die SQL schieben.

     

    Falls du Fragen hast, darfst du mich gerne kontaktieren.

     

    Gruß

    Oliver Hauth

    Montag, 10. Mai 2010 09:27