Rundgang durch die MyRapidi-Konfigurationsoberfläche
Hallo und willkommen zur heutigen Session. Ich führe Sie durch die Datenintegrationslösungen von Rapidi und zeige Ihnen, was wir bei Datenintegrationsprojekten leisten können.
Zunächst zu mir: Mein Name ist Andreea. Ich möchte Ihnen etwas über Rapidi erzählen und Sie durch die Konfigurationsoberfläche führen
Einführung
Rapidi bietet Lösungen für cloudbasierte Datenintegration, Replikation und Migration. Sie sind cloudbasiert, wir bieten aber auch hybride Lösungen und On-Premise-Services, also lokal installierte Services.
Mit unserer Technologie können wir natürlich jedes System und jede Datenbank integrieren oder replizieren, unser Fokus liegt aber auf Integrationen zwischen Salesforce und den Microsoft Dynamics-Produkten.
Wenn wir über RAPIDI sprechen, müssen wir über iPaaS sprechen, eine Integration Platform as a Service. Das heißt, wir stellen Cloud-Services bereit und ermöglichen die Entwicklung und Ausführung von Integrationsflows. Und wir können sowohl Cloud- als auch On-Premise-Anwendungen verbinden, ebenso Services und jede andere Art von Daten, in jeder Kombination und für jede Art von Unternehmen.
Zu iPaaS gehört, wie erwähnt, auch, dass Ihre Daten nicht zwischengespeichert werden, es gibt also kein Staging, und dass die Konfiguration sehr einfach ist. Sie brauchen keine Programmiererfahrung und kein Spezialwissen, und wir können mehrere Systeme und Unternehmen verbinden. Diese Möglichkeit bringt die Plattform mit. Wir verarbeiten jede Art von Daten, ob benutzerdefiniert oder Standard, im Grunde jede Art von App. Unsere Abonnements sind All-inclusive: Wir bieten Pakete, die alles enthalten, was Sie brauchen, damit Ihre Integration vollständig umgesetzt wird.
Geschäftsprozess Quote to Cash
Ich möchte Ihnen jetzt an einem Beispiel zeigen, wie das funktioniert, und anschließend die Integrationsplattform von Rapidi vorstellen.
Sehen wir uns zuerst dieses Beispiel an, ein Quote-to-Cash-Beispiel. Links sehen Sie das Salesforce-Objekt, rechts die ERP-Objekte, beziehungsweise die Tabellen.
Hier wird zum Beispiel ein Lead angelegt und konvertiert, und das löst das Anlegen von Account, Kontakt und Opportunity aus.
Accounts, Kontakte und Opportunities werden synchronisiert und an das ERP-System gesendet. Ein Account wird im ERP als Kundendatensatz angelegt, ein Kontakt wird ein Kontakt, und aus der Opportunity beziehungsweise dem Angebot wird ein Verkaufsauftrag.
Sie sehen hier: Daten können in eine Richtung laufen, aber auch zurück ins ERP. Das sind dann bidirektionale Transfers. Wie das konfiguriert wird, entscheiden Sie als Kunde, abhängig von Ihren Geschäftsprozessen.
Sobald Kunden, Kontakte und Verkaufsaufträge im ERP vorliegen, können wir diese Informationen zurück an Salesforce senden. Verkaufsaufträge gehen in diesem Fall als offene Verkaufsaufträge zurück. Rechnungen und Zahlungen lassen sich ebenfalls an Salesforce zurücksenden, als Verkaufshistorie und als Zahlungshistorie. Alle Informationen können also in beide Richtungen fließen, und alles bleibt aktuell, solange der richtige Prozess eingerichtet ist.
Rapidi-Terminologie
Zur Konfigurationsoberfläche von MyRapidi gehört auch ein kurzer Blick auf die Rapidi-Terminologie, die wir verwenden.
Zunächst gibt es die Connections: Eine Connection ist eine Verbindung zwischen zwei Systemen, Datenbanken oder beliebigen Unternehmen beziehungsweise Entitäten.
Transfers: Transfers bestehen aus Tabellen, Feldern, allen Mappings, Filtern und Datenkonvertierungen, die für Ihr Unternehmen gelten.
Schedules: Ein Schedule steuert, wie Ihre Transfers ausgeführt werden. Zum Beispiel, wie oft sie laufen sollen und wann genau sie laufen sollen. Es geht also um Häufigkeit, Zeitpunkt und alles, was mit der täglichen Ausführung zu tun hat.
System Log: Dann gibt es das System Log, das Ihnen zeigt, was auf unserem Server passiert. Wichtig ist dabei: Wir speichern keine Daten. Die übertragenen Daten werden von uns nicht gespeichert.
Templates: Templates enthalten vordefinierte Geschäftsprozesse und wurden entwickelt, um Sie als Kunden bei Ihrem Datenintegrationsprojekt zu unterstützen. Sie sind nämlich vorgefertigt und erfüllen die Anforderungen auf beiden Seiten, in Ihrem CRM- und in Ihrem ERP-System. Mit den vorgefertigten Templates sind alle Standardfelder bereits angelegt und einsatzbereit.
Wenn Sie als Kunde einfach eine Standardlösung einführen möchten, können Sie die Templates direkt verwenden und mit Ihren eigenen Daten testen. Mit den Templates sparen Sie viel Zeit, viele Ressourcen und natürlich Geld, weil auf Ihrer Seite niemand für Entwicklung, Mappings oder Ähnliches eingeplant werden muss. Das spart Zeit und schafft Mehrwert im gesamten Prozess.
Sie profitieren so sehr früh im Projekt von der Integration. Sie müssen nicht einige Monate warten, bis das Mapping fertig ist, und dann mit dem Testen beginnen. Sie können sofort starten, die Lösung nutzen und mit dem Testen anfangen. Damit bleibt mehr Zeit, Ihre eigenen Anwendungsfälle zu testen und sicherzustellen, dass Ihre Daten korrekt sind.
Service: Der Service ist die eigentliche Engine, die die gesamte Integration ausführt. Er enthält alles, was ich oben genannt habe: Connections, Transfers, Schedules und weitere Funktionen, die bereits verfügbar sind.
Die MyRapidi-Konfigurationsoberfläche
Dashboard
Sehen wir uns nun die Rapidi-Plattform an. Das hier ist ein Beispiel für einen Service.
Hier sehen Sie den Status Ihres Service, wann er abläuft, und Ihre Edition. Der Service-Status gibt Ihnen einen Health-Check Ihres Service: Sie sehen, wie es läuft, und falls es Probleme gibt, erkennen Sie sie hier auf jeden Fall. Dazu kommen zwei weitere Funktionen. Die erste ist die Möglichkeit, den Service neu zu starten: Wenn Sie lokal Probleme haben oder Ihren Server lokal neu starten müssen, können Sie das auch hier tun, um sicherzustellen, dass alles korrekt verbunden ist. Die zweite ist, alle Schedules zu verzögern.
Sie können alle Schedules verzögern, zum Beispiel wenn Sie zusätzliche Entwicklungsarbeiten durchführen möchten, ohne Ihre Schedules zu beeinträchtigen. Wenn Schedules laufen, müssen Sie sie natürlich verzögern. Dann können Sie ohne Probleme arbeiten.
Wenn Sie keine Schedules haben, brauchen Sie diese Funktion nicht.
Connections
Als Nächstes schauen wir uns die Connections an. Connections sind, wie gesagt, der erste Schritt bei der Arbeit an Ihrer Integration.
Sie müssen Ihre Quell- und Ziel-Connections einrichten und sicherstellen, dass sie einwandfrei funktionieren.
Um eine Connection einzurichten, wählen Sie hier in der Liste den Reiter Connections und klicken auf "new connection".
Danach füllen Sie alle erforderlichen Informationen aus. Wenn ich hier beispielhaft eine Connection öffne, sehen Sie die Felder, die Sie ausfüllen müssen. Ein Feld ist dabei entscheidend: die Art der Authentifizierung. Sie bestimmt, welche weiteren Felder hier angezeigt werden, je nachdem, ob Sie Basic, Token oder Azure AD verwenden.
Das sind die Informationen, die Sie üblicherweise eintragen. Beim Einrichten einer Connection haben Sie natürlich immer die Wiki-Seite zur Hand. Sie sehen hier in jedem Abschnitt das Fragezeichen. Wenn Sie es in einem anderen Tab öffnen, finden Sie Informationen dazu, wie eine Connection konfiguriert wird, was Sie dort eintragen müssen und alles, was dazugehört. Die Wiki-Seite können Sie jederzeit und für jede Tätigkeit hier nutzen.
Das ist sehr praktisch, wenn Sie Ihre Connection selbst einrichten möchten.
Weiter geht es mit den Connection-Details. Sobald sie vollständig konfiguriert sind, speichern Sie sie einfach. Der nächste Schritt ist Test: Sie müssen die Connection testen und sicherstellen, dass sie tatsächlich funktioniert. Sie klicken auf Test, und dann sollte eine Meldung erscheinen, dass die Verbindung erfolgreich hergestellt wurde. Wenn Sie Fehlermeldungen erhalten, prüfen Sie alle eingetragenen Informationen und stellen sicher, dass sie korrekt sind.
Der zweite Schritt ist Redesign. Redesign erlaubt dieser Connection, alle Tabellen zu lesen, die in Ihrem System verfügbar sind. Wichtig dabei: Diese Tabellen müssen veröffentlicht sein.
Diese Seiten müssen veröffentlicht sein. Sie müssen also für uns verfügbar sein, damit wir sie lesen können.
Jedes Mal, wenn Sie in Ihrem Quellsystem eine Seite veröffentlichen, führen Sie deshalb ein Redesign durch, denn wir lesen nur, was tatsächlich verfügbar gemacht wurde, nicht alles, was Sie auf Ihrer Seite haben.
Das wäre es zu den Connections.
Und dann schauen wir uns die Transfers an
Transfers
Weiter zu den Transfers
Wie Sie sehen, sind die Templates hier schon vorhanden. Oben finden Sie einige Filter, die Ihnen helfen, die Transfers zu sehen oder zu finden, die Sie interessieren. Mit diesem Filter hier lassen sich zum Beispiel nur bestimmte Gruppen anzeigen.
Eine Gruppe ist eine Menge von Transfers, die zusammen laufen sollen. Es kann zum Beispiel die Gruppe Items geben. Diese Gruppe enthält etwa einen Transfer, der die Produkte für die Artikel überträgt, und einen zweiten, der die Preise überträgt. Durch die Gruppierung haben Sie die Möglichkeit, ein klares Bild davon zu bekommen, was für diese Seite aktuell vorhanden ist.
Bei Rechnungen ist es genauso: Sie haben einen Transfer für die Rechnungsköpfe und einen weiteren für die Rechnungszeilen. Beide gehören im Grunde zur selben Gruppe. So können Sie sie hier leichter organisieren.
Sie können also einen Filter setzen, der auf Items oder Customers filtert.
Sehen wir uns hier beispielhaft einen der Transfers an. Ihr Ausgangspunkt ist der Abschnitt General, hier beginnen Sie mit Ihrem Transfer.
Im Abschnitt General müssen Sie darauf achten, die richtigen Informationen einzutragen.
Zunächst die Bezeichnung: Dafür gilt eine Namenskonvention. Sie tragen eine Beschreibung ein und den Status, den der Transfer haben soll. Die Source ist das Quellsystem.
Beim Layout gilt dasselbe. Destination und Destination Layout stehen für das Zielsystem, in das Sie die Daten senden müssen. Dazu kommt die Source Table, also die Tabelle, die wir verwenden müssen, und das Ziel, an das die Daten gehen.
Link Storages
Ich zeige Ihnen nun den nächsten Abschnitt, Link Storages, und was sie leisten. Link Storages sind eine Funktion für Kunden, die die Primärschlüssel speichern möchten.
Angenommen, Sie haben mehrere Gesellschaften: eine in Dänemark, eine in Spanien, und Sie möchten die Primärschlüssel hier speichern. Es geht also um Source und Destination. In diesem Fall ist ein Link Storage konfiguriert, und Sie sehen diese Informationen hier.
Um ein Link Storage zu konfigurieren, müssen Sie die Primärschlüssel auf der Source-Seite und die Primärschlüssel auf der Destination-Seite festlegen. Sobald Sie den Transfer ausführen, füllt das System hier alle Daten. Sie sehen dann, welche Kundennummer in Business Central welcher Salesforce-Account-ID entspricht. Das System ordnet sie hier also einander zu. So können Sie diese Informationen speichern, und es hilft Ihnen, alle benötigten Angaben zusammenzuführen.
Wiki Link Storages
Wie erwähnt steht Ihnen die Wiki-Seite zur Verfügung. Hier finden Sie alle Informationen zu den Link Storages, und wenn das für Ihr Unternehmen nützlich ist, können Sie die Funktion natürlich nutzen. Wie gesagt speichern Sie Daten und können sie wieder abrufen: Sie können das Link Storage verwenden, um Daten daraus auszulesen und als Referenz zu nutzen.
Es kann also alles Mögliche sein. Besonders nützlich ist das für Unternehmen mit mehreren Gesellschaften oder mehreren Standorten, die alle Daten im Blick behalten möchten, die sie aktuell haben.
Das wären die Link Storages. Sie lassen sich bei Bedarf auf einem bestimmten Transfer verwenden. In diesem Fall können Sie auf diesem Transfer bestimmte Tags nutzen. Sie sehen hier, dass es Link Storages und Tags gibt. Beide gehören zusammen, denn im Setup dieses Transfers zeigt das Link Storage alle Tags, die wir konfiguriert haben.
Tags
Ich zeige Ihnen die Tags, damit das verständlich wird.
Hier sind also die Tags. Tags sind Parameter, die wir für die Datenübertragung verwenden. Sie können sie als Kriterium verstehen, das Sie festlegen möchten, und genutzt wird das, wie gesagt, von Unternehmen mit mehreren Gesellschaften, etwa einem Unternehmen mit Standorten in Dänemark, Spanien, Frankreich und Deutschland, das seine Daten getrennt halten möchte. Dann haben Sie hier einen Tag und einen Tag-Wert für jede Gesellschaft: einen für Dänemark, einen für Spanien und ebenso für die weiteren Gesellschaften.
In diesem Tag hinterlegen Sie Informationen über die Gesellschaft und legen fest: Das ist die Connection, zum Beispiel für Dänemark, dann haben Sie die Salesforce-Connection, die wir verwenden müssen, und das sind die Link Storages, die wir nutzen möchten.
Deshalb sagte ich, dass Link Storages und Tags zusammengehören: Auf der einen Seite steht das Link Storage, das im Grunde als Lookup-Tabelle funktioniert, auf der anderen Seite stehen die Tags, die das Link Storage einbeziehen und weitere Kriterien hinzufügen.
Wenn Sie mehrere Gesellschaften haben, können Sie denselben Transfer verwenden, nur einen einzigen Transfer, und mit den eingerichteten Tags Daten für zum Beispiel fünf Gesellschaften gleichzeitig übertragen. Dafür müssen Sie aber das Link Storage eingerichtet haben und zusätzlich die Tags. Unter Tags und Tag Values sehen Sie, wie Ihre Transfers auf Basis der konfigurierten Tags laufen. Im Abschnitt Tag Values sehen Sie in diesem Beispiel, welche Connection, welche Company, welche Salesforce-Instanz und welches Link Storage verwendet werden; die letzten 3 Spalten sind die Parameter aus dem Transfer selbst, nämlich Customers, Orders und die Beschreibung. Oben im Abschnitt Tags finden Sie außerdem eine kurze Beschreibung dazu, was die Tag Values bedeuten und wie sie verwendet werden. Wenn Sie nur eine Gesellschaft haben, brauchen Sie weder Link Storages noch Tags: Dann verwenden Sie den Transfer einfach so, wie er ist. Wenn Sie aber sicherstellen möchten, dass Ihre Daten an einer Stelle zusammenlaufen, können Sie beides kombinieren. Damit arbeiten Sie beim Senden von Daten deutlich effizienter.
Wie gesagt: Bei den Link Storages können Sie jedes verwenden, das hier im Dropdown Link Storage unter dem Transfer aufgeführt ist. Wichtig ist außerdem, dass Sie bei Source und Destination auch die Tags verwenden können, die Sie eingerichtet haben. Im Dropdown Source können Sie zum Beispiel diesen Tag hier auswählen (TAG: COMPANY - CONN), der die Daten dann auf Basis der hinterlegten Tags überträgt. Sie haben hier zwei verschiedene Gesellschaften, und Rapidi weiß, wie die Daten weitergeleitet und wohin sie gesendet werden müssen. Das lässt sich also für die Fälle konfigurieren, in denen Sie mehrere Gesellschaften haben.
Wenn das bei Ihnen nicht der Fall ist, richten Sie einfach die Source ein, und das war es. Sie senden die Daten dann ohne Probleme. Als Randbemerkung: Hier rechts, im Abschnitt General dieses Transfers, finden Sie alle Funktionen und Aktionen, die ausgeführt werden können. Erläuterungen zu jeder einzelnen finden Sie auf der Wiki-Seite.
WIKI: Aktionen von Transfers
Das Wiki ist die zentrale Anlaufstelle, die jeder Kunde jederzeit nutzen kann, um sicherzugehen, dass alles verständlich ist.
Hier wird alles erklärt: was jede Aktion tut und wie Sie sie verwenden müssen. Die Wiki-Seite ist ausgesprochen gut, Sie finden dort alle Informationen, die Sie dazu brauchen.
Dann haben wir das Source Control. Es ist hier. Das ist der Abschnitt, in dem Sie im Grunde steuern, was Sie senden. Sie haben eine Steuerung auf der Source-Seite und auf der Destination-Seite. Sie können ein Feld festlegen, das steuert, was gesendet wird, zum Beispiel Zeitstempel-Felder. Damit ist klar, was gesendet werden muss. Dasselbe können Sie natürlich auch auf der Destination-Seite tun.
Transfers: Table Links
Bei den Table Links geben Sie an, welches die Primärschlüssel sind, auf der Source-Seite und auf der Destination-Seite. Wenn Sie einen Transfer für Kunden haben, gibt es dafür in Ihrem Quellsystem einen Primärschlüssel, und für die Destination gilt dasselbe.
Weiter mit dem Field List Mapping. Hier sehen Sie alle Felder, die bereits Teil des Templates sind. Links steht die Source, rechts die Destination. Sie fügen hier einfach das Feld hinzu, das Sie möchten. Wenn Sie zum Beispiel nur "number" eingeben, erhalten Sie das Feld, das im Quellsystem aktuell verfügbar ist. Für die Destination gilt dasselbe, dort muss es eine Entsprechung geben. Was Sie hier sehen, ist eine Formel. Und wir haben eine ganze Reihe von Formeln, die für Integrationen genutzt werden können.
Transfers: Field List Mapping Formula
Formeln lassen sich verwenden, wenn es keine 1:1-Entsprechung gibt. Ich zeige hier zum Beispiel die Liste mit allen Formeln, die Sie verwenden können, jeweils mit einer Erläuterung. Sehen wir uns diese hier an: Das wäre ein Lookup auf das Link Storage. Sie erhalten eine Erläuterung und Beispiele, wie Sie die Formel verwenden können.
Wiki: Formeln
Dazu kommen weitere Formeln, zum Beispiel DB Lookup, die sehr häufig verwendet wird. Damit können Sie einen Wert aus einem bestimmten Feld in einer anderen Tabelle nachschlagen. Wenn Sie also ein Feld mappen möchten, das nicht in Ihrer Tabelle liegt, holen Sie es per Lookup von einer anderen Stelle. Auch hier finden Sie Erläuterungen zur Verwendung und zur Bedeutung, dazu Tipps und Beispiele, wie es aussehen sollte. Selbst wenn es keine 1:1-Entsprechung gibt und Sie ein Feld von anderswo brauchen, können Sie ein Lookup verwenden und die Daten aus einer anderen Tabelle ziehen. Formeln sind also wirklich nützlich, wenn Sie Daten in einem bestimmten Format übertragen müssen oder Daten aus einer bestimmten Tabelle holen möchten, die hier im Transfer nicht enthalten ist.
Feld zum Mapping hinzufügen
Und wenn Sie neue Felder hinzufügen möchten, klicken Sie einfach auf New, tragen das Feld aus Ihrem Quellsystem ein und dann das Feld aus Ihrem Zielsystem. Sehr praktisch ist hier Browse Table Layout: Damit sehen Sie das Layout der Source. Hier sehen Sie zum Beispiel die Debitorenkarte und können nach bestimmten Daten suchen. Nehmen wir "Bill to Customer No.": Dieses Feld konnte ich finden, es liegt in meinem Quellsystem und ist damit verfügbar, Sie können es also verwenden. Angegeben sind auch der Typ, hier muss es ein String sein, und die Größe. Das ist ziemlich einfach, Sie finden Ihr Feld also auf jeden Fall. Wenn Sie es direkt hinzufügen möchten, können Sie das tun. Wenn nicht, durchsuchen Sie einfach das Table Layout und finden es dort. Wenn Sie ein Feld deaktivieren möchten, klicken Sie auf die Funktion Disable: Damit wird die gesamte Zeile deaktiviert und durchgestrichen. Sie können sie einfach so stehen lassen. Die Zeile ist dann deaktiviert, erscheint aber weiterhin im Transfer, wird beim Ausführen des Transfers jedoch nicht berücksichtigt.
Schedules
Sie sagen also: Ich möchte einen Schedule für Rechnungen einrichten. Dann laufen alle Transfers der Gruppe Invoices als Teil dieses Schedules.
Hier tragen Sie eine Beschreibung ein und das Intervall: Wie oft soll der Schedule laufen?
Priority: Sie können Prioritäten festlegen und sagen: Dieser Transfer hat hohe Priorität, er muss jedes Mal zuerst laufen, und der andere hat niedrige Priorität. So weiß Rapidi, welcher der wichtigere ist.
Logs
Mit den Schedules verknüpft sind die Logs. Die Logs zeigen Ihnen drei Bereiche. Zunächst Runs: was wir bisher genau getan haben.
Sie sehen hier eher einen Zeitstempel der ausgeführten Aktivität. Dann gibt es die Logs mit allem, mit jeder einzelnen Aktion, die wir auf diesem Service ausgeführt haben. Und schließlich die Data Errors: Sie erscheinen, wenn tatsächlich Datenfehler auftreten. Wenn Ihr Transfer läuft und Datenfehler auftreten, sehen Sie sie hier aufgelistet.
Sie können Filter setzen und sich bestimmte Fehler von bestimmten Tagen ansehen. Sie legen fest, wann der Zeitraum beginnt und wann er endet, und wählen hier alle Transfers oder auch nur einen bestimmten Transfer aus.
Sie können nach Source und Destination filtern, und mit dem letzten Filter hier nach Fehlern, die nicht behoben wurden, nach behobenen Fehlern oder einfach nach allen. Das ist hier möglich.
Anschließend sehen Sie die angezeigten Fehlermeldungen. Natürlich gibt es auch hier die Wiki-Seite. Sie erklärt alles zu Data Errors, Logs und Runs und hilft Ihnen dabei, die Nutzung zu verstehen.
RTI
Und das letzte Thema für heute ist RTI.
RTI ist eine weitere Funktion, die wir sozusagen anbieten. Ich zeige die Wiki-Seite, damit Sie alle Informationen dazu sehen. RTI ist eher ein Nachschlagewerk: Es hält fest, wann Daten übertragen wurden. Es weiß also, dass der Transfer gestern zu diesem Zeitpunkt beendet wurde. Beim nächsten Lauf weiß Rapidi dann, dass es dort weitermachen muss, wo es aufgehört hat. Damit vermeiden Sie, Transfers jedes Mal vollständig laufen zu lassen.
Stattdessen werden nur die Daten durchlaufen, die sich geändert haben. So wird keine Zeit für Aufgaben aufgewendet, die bereits erledigt sind. RTI weiß gewissermaßen, wo der Transfer gestoppt hat, und setzt beim nächsten Mal dort fort. Das ist in bestimmten Fällen nützlich, es ist eine Funktion, die wir anbieten, und Kunden können sie natürlich nutzen.
Das wäre im Großen und Ganzen alles zur Datenintegrationsanwendung und -plattform von Rapidi.
Wie erwähnt finden Sie hier das Fragezeichen, über das Sie zur Wiki-Seite gelangen. Dort können Sie alles über unsere Funktionen nachlesen und über die Schritte, die Sie durchlaufen müssen, um Ihre Integration abzuschließen.
Das war es. Vielen Dank fürs Zuhören, ich hoffe, es hat Ihnen gefallen. Wenn Sie Fragen haben, melden Sie sich gern bei uns und abonnieren Sie, falls noch nicht geschehen, unseren Produkt-Updates-Blog, um Neuigkeiten und Updates zu neuen Funktionen und Verbesserungen an der MyRapidi-Konfigurationsoberfläche zu erhalten.
Vielen Dank, Andreea Anseni - Data Integration Consultant bei RAPIDI.