B2B by Practice

1. B2B by Practice Netweaver, ESA, SAP, R/3, ABAP/4 und mySAP.com sind eingetragene Marken der SAP AG, Walldorf. Alle Rechte vorbehalten.Java, EJB, Sun-One and J2EE sind eingetragene Marken von Sun Microsystems, Inc. Alle Rechte vorbehalten.

2. Hintergrund • Hinter B2B by Practice steht die Next Level Integration GmbH, die eine Open Source Datenaustauschlösung konzipiert und entwickelt hat • In die Lösung sind Erfahrungen aus über 50 Datenaustauschprojekten in der Energiewirtschaft geflossen • Die Next Level Integration GmbH stellt die Lösung unter einer GPL Lizenz kostenlos zur Verfügung. • Keine Lizenzgebühren • Professional Services (Software Support und Content) sind kostenpflichtig • Es gibt mehrere IT Dienstleister, die für diese Lösung professional Services anbieten • Kunden können die Lösung beeinflussen • Lösung wird langfristig weiterentwickelt und gewartet • Status: bei > 12 Kunden im Einsatz (Jan 2009)

3. B2B by Practice: Mandantenkonzept versus Multideployment Alternativ kann für jeden Martkrolle eine seperate B2B Engine genutzt werden Aufgrund des Mandantenkonzeptes können mehrere Marktpartner übereine B2B Engine versorgt werden. B2B by Practice Mail,Files,WebService,.. B2B by Practice Mail,Files,WebService,.. B2B by Practice B2B by Practice B2B by Practice

4. Supported Platforms • J2EE 1.4 & EE 5.0 kompatible Application Server • z.B SAP J2EE Engine (incl SAP PI) • Tomcat / JBOSS • …. • Datenbanken • Produktivbetrieb: Oracle, MAXDB, DB2, MSSQLServer • Test: Derby, MySQL • Betriebssysteme • Keine Einschränkungen Netweaver, ESA, SAP, R/3, ABAP/4 und mySAP.com sind eingetragene Marken der SAP AG, Walldorf. Alle Rechte vorbehalten.Java, EJB, Sun-One and J2EE sind eingetragene Marken von Sun Microsystems, Inc. Alle Rechte vorbehalten.

5. Architektur • leichtgewichtige Architektur • gute Skalierung / Plattformunabhängig • Trennung zwischen Contententwicklung und Engineentwicklung • Modellgetriebene Softwareentwicklung • Persistenz der Daten, um Nachweispflichten zu erfüllen • P2P Ansatz und kein Hub Ansatz, um Nachweispflichten zu erfüllen • Klare Trennung des Datenaustauschs für z.B. verschiedene angebundene Systeme • Variante 1: Mandantenkonzept • Variante 2: Multideployment (physikalische Trennung) • Klare Trennung IT Betrieb / Fachbereichsaufgaben ist in der Architektur verankert • Oberflächen sind stark konfigurierbar • Lösung ist optimal auf kundenindividuelle Erweiterung vorbereitet • Custom Content • Erweiterungskonzept für Verarbeitungslogik

6. Übersicht Architektur Technologie: Adobe Flex, läuft im Flash-Plugin des Browers, oder als Desktopanwendung in Adobe AIR UserInterface J2EE 1.4 & EE 5.0 kompatible Application Server J2EE Server DB Relationale Datenbank mit JDBC Schnittstelle 6

7. Interne Architektur Monitoring Action Action Action Action Action Action Action Action Action Empfänger Ermittlung File | Smtp | http | Soap File | Smtp | http | SAP Channel-Distributuion Formaterkennung Action Action Action Fehlerbehandlung • Setzt sich aus verschiedenen Komponenten zusammen • Schnittstellenfunktionen (Services) • Querschnittsfunktionen (Monitoring, Fehlerbehandlung) • Workflowcontainer (Formaterkennung, Channeldistribution, Channels, Actions, Empfängerermittlung) • Für alle gibt es Interfaces, um einfache Erweiterung zu ermöglichen 7

8. Community: http://www.b2bbypractice.org/

9. Funktionsumfang • Info für Kunden, die die SAP® IDEX-GE-XI Lösung einsetzen • 1:1 Migration ~ 5-10 Tage • Alle Features der SAP® IDEX-GE-XI Lösung werden unterstützt. • Der XI Content (Mappings, Schemata) kann übernommen werden. • Verarbeitung aller Marktformate Strom und GAS • Content wird im Rahmen der professional Service geliefert • Aperak (Modellprüfung) auf B2B by Practice • Einhaltung der gesetzlichen Anforderungen • z.B. gezippete Mails verarbeiten • Konfigurierbare Formaterkennung (EDI und XML) • Zuweisung zu Workflowchannels über Distribution Extensions • Umfangreiche Extensions (z.B. Zuordnung über BDEW Nr.) vorhanden • Abbildung der Workflows über Channels • Abbildung von automatischen, halbautomatischen oder manuellen Prozessen mit Benutzerfindung • Bereitsstellung einer Bibliothek von Workflowschritten („Actions“) mit denen die Marktanforderungen abgedeckt werden • z.B: Splitt von Nachrichten nach Postleitzahlen • z.B: Umsetzung 1:1 Kommunikation bei Einbindung eigener Dienstleister • z .B:Content für Systemtrennungsszenarien

10. Funktionsumfang • Anbindung von Systemen über Services • File, Mail, SAP, HTTP,.. • Customizingtransport • Generierung von Dokumentation aus dem Customizing • Trennung von Standard und Kundenobjekten für Content und Coding • Volltextsuche • Spezielle UTMIL Suche auf Positionsebene mit Verknüpfung der ein- und ausgehenden Vorgängen • Standalone EDI Analyzer • Formulardesigner für Umsatzsteuernachweise • Auswertereports und Exceldownload • Unterstützung von manuellen Prozessen durch Anbindung von Mail oder Ticketsystemen • Anbindung an Signaturlösungen • Archivierungsschnittstelle incl. SAP Integration • Abgleich mit SAP IDOC Status • Template Engine für Texte und Variablen mit Zugriff auf den Workflowcontainer • Command Event Parser für beschleunigte XPath Verarbeitung

11. Funktionsumfang • Internationalisierung • Berechtigungskonzept • Mandantentrennung • Adminstrations- und Customizing Funktionen • Queueverwaltung • Systemfehler • Sperrverwaltung • Benutzerverwaltung • Contentverwaltung • Customizing • Long Running Transaction Monitor • Clusteradministration • Fachbereichs- / IT-Monitoring • Korrelationshandling (z.B. CONTRL, APERAK) • Mandantenkonzept • Monitore individuell einstellbar • anpassbares Logging und Tracing • Mime Viewer zum Anzeigen der Emails innerhalb des Monitorings • Birt-Anschluss für Reporting • Entwicklungsunterstützung • Bereitstellung von APIs um kundenindividuelle Erweiterungen modifikationsfrei und upgradesicher bauen zu können • Developer Workplace

12. Professional Services Offerings Phase 1 (kostenlos): • WebEX zur Lösungsvorstellung durch Initiatoren und/oder Vorstellung der Lösung durch einen B2B by Practice Partner (vor Ort) • Referenzkundenbesuche  Vermittlung über info@b2bbp.org Phase 2: • Assessments • Pilotierung Phase 3: • Einführung • Training Phase 4: • Content (incl. Updates) und Entwicklungssupport

13. Screenshots - Statistiken Since August 7th this customer processes more than 20.000 Messages a day (Hardware usage is only 5%) a 75MB Message is processed in 15min

14. SAP Statusinformationen im Monitoring SAP IDOC Nr

15. CONTRL und APERAK Zuordnung zum führenden Beleg Contrl und Aperak Nachrichten werden im Monitoring zur führenden Nachrichtüber die Referenznr zugeordnet. Der letzte Contrl oder Aperak Beleg wird in der führenden Nachricht in der Spalte BS (Bestätigungsstatus) durch ein Symbol dargestellt. B2B hat einen Jobscheduler und einen Werkskalender für das Fristenmanagement B2B erzeugt Contrl und Aperak (Modellprüfung) für eingehende EDIs. Sofern Aperak imBackend realisiert wurde, kann dieses angeschlossen werden

16. Nachricht verschicken und Contrl / Aperak empfangen (und Aperak mit Contrl quittieren)

17. Nachricht empfangen und Aperak senden (und Contrl für Aperak empfangen)

18. Massenverarbeitung Die Last kann für die einzelnen Clusterknoten separat verteilt werden - sowohl für die Services als auch für die Nachrichtenverarbeitung gestaffelt nach small, medium und large MessagesFür sehr große Nachrichten kann eine Exclusivverarbeitung eingestellt werden.

19. Massenverarbeitung: Fortschrittsmonitor für große Nachrichten

20. Volltextsuche

21. UTILMD Suche – Korrelation von ein- und ausgehenden UTILMDs

22. Statusänderung / Massenrestart Mit der Statusänderung können einzelne oder mehrere Datensätze im Status geändert oder neu angestartet werden Der ausgewählte Status wird anschließend als Zahl in der Spalte CS (Clearingstatus) angezeigt und ist damit auswertbar. Der Kurztext und der Langtext können sinnvoll gefüllt werden.

23. Changelog: Die Clearing-Historie (wer wann was) wird fortgeschrieben Der zuletzt gesetzte ClearingCode wird angezeigt

24. Weiterleiten von Mails Bei Bedarf können Mails aus der B2B heraus weitergeleitet werden.

25. Beispiel für Tastatursteuerung Die Referenznummer des markierten Satzes kann mit der Tastaturkombination Shift + R in die Volltextsuche übernommen werden!

26. Datumsfilter auch bei Volltextsuche Das Ergebnis einer Volltextsuche wird unter Berücksichtigung des Datums- und Zeitfilters im Monitor angezeigt. Wird das Datum geändert, ändert sich auch die Anzeige der Einträge in der Tabelle!

27. Berechtigungskonzept: Einschränkung von Funktionalität und Systemen

28. Customizing: Content (hier kann z.B. XI Content hochgeladen werden) Pflege von Benutzern, Rollen und Berechtigungen

29. Formaterkennung Customizing – Command Event Parser

30. Pflege von Workflowdefinitionen

31. Pflege von Workflowschritten

32. Pflege von Services

33. Systemfehlerübersicht / Logviewer

34. Sperrverwaltung

35. Customizing Download und Dokugenerierung

36. CHEFAUSWERTUNGENBelegabgleich auf Basis der B2B by Practice Informationen: Hier Invoice/Remadv-Abgleich OK* Inhaltlicher Fehler* Remadv wegen falschem Format abgelehnt** Invoice mit neg Contrl abgelehnt* Remadv mit neg Contrl abgelehnt** noch keine Antwort* OK* *diese Info kann auf viele Backendsystem / Dienstleister verteilt sein **diese Info ist in den Backendsystemen nicht vorhanden

37. Weitere Zusatzfunktionen: manueller Mailversand über B2B, Formulardesigner, EDI Validierung,..

38. Kundenbeispiel für die Practice Ordercollaboration/Lieferantenportal

39. Lasttestergebnis: Hardware + Konfigbeispiel für > 50 Mio Geschäftsvorfälle / Tag:Anmerkung: Dies ist KEINE Hardware- oder Betriebsystemempfehlung. Geschäftsvorfall = UNH Klammer: z.B eine Rechnung im aggregierten INVOIC 4 DualCore Prozessoren UI E,L,M,S* Worker Worker L,M,S DB Worker S Worker S Services Worker S B2B Cluster mit 7 Instanzen *Nachrichtengrössen E=Exclusiv,L=Large,M=Medium,S=Small

40. Clusterinstallation Workflows abarbeiten Filewriter Mailsender SAP Callback SAP Sender 1 Userinterface Housekeeping Services: ContrlScheduler, indexservice QueueRestarter 3 queue_3 E,L=5,M=10,S=30 DB Filewriter Mailsender SAP Callback SAP Sender 4 queue_4 L=5,M=10,S=30 Queueservice Filelistener IDOC-Neu 2 Daten entgegenehmen/holen: MailCrawler, Filelistener http-Empfang von SAP Filelistener IDOC-alt Filewriter Mailsender SAP Callback SAP Sender 5 queue_5 S=30 6 queue_6 S=30 MailCrawler 7 queue_7 S=30 SAP auf 8090 (2 Ports für alte und neue IDOCs) MailCrawler :66CONTRLScheduler :3000 Index_Service :index QRestart QRestart Filelistener WORLD_2_Engine :7 Filelistener ERP_2_Engine :1 Filelistener ERP_2_Engine_oldIdocs:11 Filelistener ERP_2_Engine-NLC:111 queue_3 queue_4 queue_5 queue_6 queue_7

41. Best Practices - logische Rückmeldeprozesse (CONTRL, APERAK, REMADV, UTILMD,..) Dr. Stefan Klose sklose@next-level-integration.com http://www.next-level-integration.com

42. Rückmeldeprozesse: Worum geht es? Im Datenaustausch werden neben den logischen Antwortnachrichten (z.B. REMADV und UTILMD) Eingangsprüfungen durch eine CONTRL (Empfangsbestätigung und Syntaxprüfung) und ggfs. eine APERAK Nachricht (Modellfehlermeldung) ausgetauscht. Denkbare Verarbeitungsfehlermeldungen und Anerkennungsmeldungen werden derzeit nicht gefordert. Die Anforderungen an die Rückmeldeprozesse können lückenlos mit B2B by Practice im Standard abgebildet werden. Dies beinhaltet ein komfortables Customizing und Monitoring der Rückmeldenachrichten, ein Fristenmanagement und die Verknüpfung mit den Backendbelegen. Architektonisch ist es nur auf B2B by Practice möglich, systemübergreifend (SAP, nonSAP) alle Rückmeldugen zentral zu monitoren.

43. Rückmeldeprozesse Beispiel: eingehende Nachrichten B2B B2B Lastgänge nonSAP Lastgänge nonSAP APERAK CONTRL TL CONTRL TL TL TL MSCONS MSCONS Zählerstände SAP VL VL VL CONTRL CONTRL 4711 4711 Zählerstände SAP APERAK 4712 4712 4713 4713 Variante A Variante B SAP Status (IDOC, ….) • Das NON SAP System hat ein eigenes CONTRL und APERAK Handling. B2B greift hier nicht ein, sondern routet diese Nachrichten weiter. Dadurch wird die 1:1 Kommunikation gewährleistet, die Vorgänge sind im systemübergreifenden B2B Monitoring incl der Volltextsuche verfügbar. Rückantworten können dem richtigen System zugeordnet werden. • Das SAP System (in dem speziellen Beispiel) kann MSCONS Nachrichten mit mehreren Turnusablesungen nicht automatisch verarbeiten. Deshalb werden diese Nachrichten auf B2B gesplittet, um auf SAP Seite mehrere IDOCs zu erzeugen, die automatisch verarbeitet werden können. Für das SAP System wird das Contrl und Aperak Handling von B2B genutzt. (Das kann man natürlich auch für jedes NON SAP System nutzen). • Variante A: Wenn keine Fehler vorliegen, werden die IDOCs in SAP angelegt. Der Status (pos Contrl gesendet) wird an diesen IDOCs gesetzt. Der SAP Verarbeitungsstatus wird in das B2B Monitoring (inkl. z.B. IDOC Nr) übertragen. • Variante B: Im Fehlerfall (auf Basis Syntax- oder Modellfehlerprüfung) wird das SAP System nicht mit fehlerhaften IDOCs „belastet“. • Im B2B Monitoring werden alle Contrls / Aperaks mit direktem Bezug zu den eingehenden Nachrichten angezeigt. Die Backendbelege werden ebenfalls im B2B Monitoring incl. Verarbeitungsstatus dazu angezeigt (z.B Angabe der IDOC Nummern und SAP Status) VL 4711 4712 4713 4711 4712 4713

44. Rückmeldeprozesse Eingehende Nachrichten: Regelverarbeitung mit SAP Status 2380405 16156902

45. Rückmeldeprozesse Eingehende Nachrichten: Modellfehler (pos Contrl, APERAK) pos Contrl auf Aperak

46. Im Contrl wird dem Marktpartner detalliert der Ablehnungsgrund mitgeteilt Rückmeldeprozesse Eingehende Nachrichten: Ablehnung mit neg. Contrl

47. Rückmeldeprozesse ausgehende Nachrichten: Modellfehlerhandling (pos Contrl, APERAK)

48. Rückmeldeprozesse ausgehende Nachrichten: Modellfehlerhandling (pos Contrl, APERAK) interne Eskalation kann individuell gesteuert werden

49. Rückmeldeprozesse Fristenmanagement Die Fristen werden über Scheduler und den „Werkskalender“ von B2B überwacht

50. Rückmeldeprozesse Zusammenfassung • Auf B2B by Practice wird implizit auf Basis der BDEW/DVGW Spezifikationen eine Syntax- und Modellfehlerprüfung vorgenommen. Diese ist auch individuell einstellbar • Es müssen keine Prüfungen in den Backendsystemen vorgenommen werden. Für alle Systeme gibt es dann ein zentrales Rückmeldungshandling • Der Status des Rückmeldungshandlungs wird z.B in SAP Systeme übertragen. • Wenn dies doch gewünscht ist, kann die Prüfung für diese Systeme auf B2B deaktiviert werden • B2B by Practice ist die einzige Stelle, die über alle Systeme / Mandanten hinweg ein zentrales Monitoring erlaubt. Dies spricht für das Rückmeldungshandling auf B2B • Durch den tiefen Statusabgleich mit z.B SAP ist B2B by Practice auch in der Lage Verarbeitungsfehlermeldungen und Annerkennungsmeldungen zentral zu erzeugen, wenn diese künftig einmal gefordert werden sollten