Blog

Ein wichtiger Baustein für ein Planungssystem ist der Umgang mit dem Thema Intercompany (IC). IC tritt immer dann auf, wenn unterschiedliche Wirtschaftseinheiten eines Unternehmensverbundes untereinander Waren oder Dienstleistungen austauschen. Die daraus resultierenden Aufwände und Erträge, aber auch Forderungen und Verbindlichkeiten müssen transparent und gegeneinander abgrenzbar sein. Da die Planung durch eine Vielzahl von Planungsteilnehmern durchgeführt wird, ist die IC-Abstimmung und auch die darauffolgende IC-Eliminierung nicht trivial.

Auch in modernen Umgebungen ist CSV noch ein häufig anzutreffendes Austauschformat, da viele bestehende Systeme mit moderneren Alternativen nicht umgehen können. Zur Weiterverarbeitung in einer Big-Data-Umgebung sind jedoch andere Formate besser geeignet. Im Zusammenhang mit Kafka ist das vor allem Avro. Avro bietet ein platzsparendes Datenformat mit vielen Features, in dem das Datenschema ebenfalls mit übertragen wird. Um die Handhabung zu verbessern, kann zudem das Schema in einem Schema-Repository registriert werden.

Interaktionen mit Kunden im Bereich der Energieversorgung sind selten – ein einziger Kontakt im Jahr ist keine Seltenheit. Entsprechend wichtig ist die bestmögliche Steuerung des Kontakts. Im Fokus des vorliegenden Projekts steht der Kommunikationskanal Inbound-Call-Center.

‍

Die Welt der mittelständischen Unternehmen bewegt derzeit vor allem ein Thema: Industrie 4.0. Denn der Druck wächst enorm, da der Anschluss an die Digitalisierung nicht verpasst werden darf, um auch langfristig erfolgreich am Markt interagieren zu können. Was die meisten Unternehmen aber nicht wissen: Es müssen nicht sämtliche internen Abläufe über Bord geworfen werden, um bei den Themen Big Data und Industrie 4.0 mithalten zu können. Viel wichtiger ist es, sich die Neugier seiner eigenen Mitarbeiter zu Nutze zu machen und die Datenkultur in alle Abteilungen zu tragen. Erfahren Sie in diesem Blogbeitrag, wie auch Sie den Wandel zur Digitalisierung Schritt für Schritt meistern können.

Die Behauptung „Python ist keine typisierte Sprache“ erhöht meinen Puls mittlerweile genauso wie das vor vielen Jahren übliche „Python ist nur eine Scriptsprache“.Man muss nur schnell eine Python-Konsole öffnen und 1+"1" eingeben. Das Ergebnis ist nicht, wie z. B. bei PHP, eine 2, sondern ein TypeError. Python ist sehr wohl stark typisiert und unterscheidet zudem auch noch zwischen mutable und immutable types. Da der Code in Python erst zur Laufzeit kompiliert wird, fällt der gerade genannte Additionsfehler an sich nicht beim Programmieren, sondern erst bei der Ausführung auf.‍

Wenn ein BW-System eine SAP-HANA-Datenbank im Einsatz hat, ist es möglich, die sogenannten „Mixed Scenarios“ zu nutzen. Bei solchen Szenarien kann man Daten zusammenspielen, die sowohl im BW-System als auch in SAP HANA mit SAP-HANA-Werkzeugen modelliert wurden.

Mit der neuen Funktionalität „zellbasierte Eingabesteuerung“ ist es möglich, zellbasiert das Eingabeverhalten in Longview zu steuern. Sobald die Funktionalität aktiviert wurde, kann über ein Referenzobjekt die manuelle Eingabe sowie das Kopieren und das Einfügen gesperrt bzw. freigegeben werden.

Mit der Migration auf SAP BW/4 HANA oder der Aktivierung des BW/4-HANA-Modus, der hier beschrieben ist, können Legacy-Objekte nicht mehr genutzt werden. Darunter fallen auch die beliebten MultiProvider. Diese werden genutzt, um verschiedene InfoProvider zu kombinieren und eine Abstraktionsschicht zu einer BW-Query herzustellen. Dabei können Objekte der InfoProvider verbunden werden, auch wenn diese in einem der Provider nur als Navigationsattribut vorliegen, also nicht direkt in der Faktentabelle des InfoProviders. In diesem Beispiel wird das Land einmal direkt und einmal als Navigationsattribut vom Kunden zugeordnet.

SAP BW/4 HANA ist nun seit genau einem Jahr für Kunden verfügbar. Grund, einmal zurückzublicken und einen Vergleich mit SAP BW on HANA 7.5 anzustreben. Zudem werde ich von vielen Kunden gefragt, was genau der Unterschied zwischen SAP BW/4 HANA und SAP BW on HANA ist. Deshalb möchte ich dies einmal darstellen.

Nach jahrelanger Arbeit an der Entwicklung von ETL-Anwendungen kann ich sagen, dass sie üblicherweise schlechter als Transaktionssysteme geprüft werden.

Noch einmal möchte ich mich mit dem Thema Speichernutzung auseinandersetzen. In anderen Blogartikeln wie „SAP HANA – kein Speicher mehr? Bewusster Early Unload!“ ist bereits die Relevanz der korrekten Einstellung der SAP-BW-Objekte für die vorgesehene Nutzung aufgezeigt worden. Zusammengefasst: Immer alles frühzeitig aus dem Speicher schieben, was nicht immer und sofort für Abfragen benötigt wird. Gesteuert wird dies über die „Early Unload Priority“, die in der HANA-Datenbank auf Tabellenebene gesetzt wird. Da diese Einstellungen nicht im ABAP-Transportwesen (CTS) enthalten sind, muss der Entwickler oder der Betrieb sicherstellen, dass diese Einstellung immer korrekt gesetzt ist. Ansonsten liegen nur für das Staging benötigte Daten aus dem „Data Acquisition Layer“ sehr performant im RAM, was unnötig teuer ist und das System belastet.

Der Teufel steckt im Detail - welche Kleinigkeiten über die Effektivität von Partition Pruning entscheiden

In dem vorhergehenden Artikel dieser Serie wurde ein praxisnaher und effektiver Ansatz zur Nutzung von Partition Pruning eingehend erläutert. Mit Hilfe dieser einfach umzusetzenden Methode können die Abfragezeiten deutlich optimiert werden. Um jedoch die effiziente und effektive Nutzung der vorgestellten Methode zu gewährleisten, müssen, wie so häufig, einige Details beachtet werden. In diesem Aspekt halten wir es mit Theodor Fontane, der schon im 19. Jahrhundert festgehalten hat, dass der Zauber immer im Detail steckt.