Der Enterprise Tenant der Cumulocity IoT-Plattform bietet verschiedene Erweiterungen zu den Funktionalitäten des Standard Tenant. Im Folgenden sind zusätzliche Funktionalitäten beschrieben, die nur im Enterprise Tenant verfügbar sind.
Ein Enterprise Tenant bietet zusätzliche administrative Funktionalitäten im Vergleich zu einem Standard Tenant. Der wichtigste Unterschied ist dabei die Mandantenfähigkeit.
Mit einem Enterprise Tenant können Sie:
Darüber hinaus bietet ein Enterprise Tenant folgende Zusatzfunktionen:
Näheres zum Cumulocity IoT-Mandantenkonzept finden Sie unter Mandantenhierarchie im Concepts Guide.
Im Folgenden sind zusätzliche Funktionalitäten beschrieben, die im Enterprise Tenant verfügbar sind:
| Abschnitt | Inhalt |
|---|---|
| Verwalten von Mandanten | Erstellen und verwalten Sie Untermandanten und verwalten Sie deren Attribute und abonnierte Anwendungen. |
| Verwalten von Benutzerhierarchien | Hiermit können Sie in Cumulocity IoT verschiedene Organisationen getrennt verwalten, die dieselbe Datenbank teilen. |
| Anpassen der Plattform | Passen Sie Ihre Plattform mit verschiedenen individuellen Konfigurationseinstellungen, der Verwendung von Branding und einem eigenen Domain-Namen nach Ihren Wünschen an. |
| Supportbenutzerzugriff | Unterstützen Sie Ihre Kunden, indem Sie mit einem Supportbenutzer auf deren Benutzer zugreifen. |
| Lizenzverwaltung | Verwalten Sie Lizenzen für die Domains der Enterprise Tenants über die Benutzeroberfläche. |
| Nutzungsstatistiken und Abrechnung | Zeigen Sie statistische Informationen zu den einzelnen Mandanten an, z. B. die Anzahl der erstellten Geräte oder Alarme, sowie zur Ressourcennutzung für jeden Microservice zu jedem Mandanten zu Anrechnungszwecken. |
| Data Broker | Teilen Sie Daten selektiv mit anderen Mandanten mit Hilfe von Datenkonnektoren und Datenabonnements. |
Über den Enterprise Tenant von Cumulocity IoT können Sie die Mandantenfunktionalität nutzen, mit der sich Untermandanten erstellen und verwalten lassen.
Um die Mandantenfunktionalität nutzen zu können, muss Ihr Benutzer über die entsprechenden Berechtigungen verfügen. Informationen zum Bearbeiten von Berechtigungen finden Sie unter So fügen Sie eine globale Rolle hinzu. Da es sich bei der Bearbeitung von Mandanten um eine sensible Operation handelt, sind die entsprechenden Berechtigungen granularer:
Klicken Sie auf Untermandanten im Menü Mandanten, um alle in Ihrem Konto vorhandenen Untermandanten in Raster- oder Listenform anzuzeigen.
Die Seite Mandanten zeigt die folgenden Informationen für jeden Untermandanten an:
Im Management Tenant finden Sie zudem Informationen über den übergeordneten Mandanten, d. h. den Mandanten, der den aufgeführten Mandanten erstellt hat.
Klicken Sie auf Mandanten anlegen rechts in der oberen Menüleiste.
Geben Sie die folgenden Attribute an:
| Feld | Beschreibung |
|---|---|
| Domain/ URL | Geben Sie eine Subdomain ihrer Wahl ein, beispielsweise "acme". Die URL des Mandanten lautet dann "acme.cumulocity.com" auf cumulocity.com. Sie können nur eine Subdomain-Ebene verwenden. Sie können zum Beispiel nur "acme.cumulocity.com" auf cumulocity.com verwenden. Sie können aber nicht "mycustomer.acme.cumulocity.com" wählen. Dies wird vom TLS-Standard nicht unterstützt. Die Mandanten-Domain kann Kleinbuchstaben, Ziffern oder Bindestriche (-) enthalten. Sie muss mit einem Buchstaben beginnen; Bindestriche sind nur in der Mitte zulässig; die Mindestlänge beträgt 2 Zeichen. |
| Name | Name des Mandanten, z. B. Name des Unternehmens. |
| E-Mail-Adresse des Administrators | Sie müssen eine gültige E-Mail-Adresse angeben, damit Benutzer ihr Passwort ändern können. |
| Benutzername des Administrators | Benutzername des Administrators dieses Mandanten. |
| Kontaktname | Optionaler Name des Ansprechpartners. |
| Telefonnummer | Optionale Telefonnummer des Ansprechpartner. |
| Link zum Zurücksetzen des Passworts als E-Mail senden | Standardmäßig ausgewählt. Wenn Sie diese Option deaktivieren, müssen Sie ein Passwort bereitstellen und dieses bestätigen (weitere Informationen zur Passwortstärke finden Sie unter Erste Schritte > Aufrufen und Anmelden an der Plattform > Anmelden an der Plattform). |
| Mandantenregel | Sie können eine Mandantenregel aus der Auswahlliste auswählen, die auf den Mandanten angewendet werden soll. |
Klicken Sie auf Speichern, um Ihre Eingaben zu speichern.
Wenn der Untermandant erstellt wird, erhält er eine automatisch generierte ID, die nicht geändert werden kann. Zudem wird er automatisch mit einem ersten Administrator-Benutzer (“Benutzername des Administrators”) eingerichtet. Dieser Administrator kann andere Benutzer erstellen und Berechtigungen vergeben. Der erste Benutzer kann nicht gelöscht werden, um ein Aussperren zu verhindern.
Vom Management Tenant aus können Sie anderen Mandanten erlauben, Untermandanten zu erstellen. Aktivieren Sie hierzu die Option Erstellen von Untermandanten zulassen im Mandanten-Editor.
Klicken Sie auf den gewünschten Untermandanten oder auf das Menüsymbol rechts im Untermandanten-Eintrag und anschließend auf Bearbeiten.
In der Registerkarte Attribute können alle Felder außer ID, Domain/ URL und Benutzername des Administrators bearbeitet werden. Detaillierte Informationen zu den einzelnen Feldern finden Sie unter So erstellen Sie einen Untermandanten.
Um das Mandantenpasswort zu ändern, klicken Sie auf Passwort ändern, geben Sie das neue Passwort in die dafür angezeigten Felder ein und klicken Sie auf Speichern.
Auf der rechten Seite der Registerkarte Attribute finden Sie Informationen zu Supportbenutzeranfragen/-zugriff für die Untermandanten.
Hier werden die folgenden Informationen angezeigt:
| Feld | Beschreibung |
|---|---|
| Status | Kann entweder "Eingeschaltet" oder "Ausgeschaltet" sein. "Eingeschaltet" bedeutet: - Supportbenutzerzugriff wurde im Management Tenant global aktiviert (siehe Administration > Plattform-Konfigurationseinstellungen). - Ein oder mehrere Untermandanten-Benutzer haben Supportbenutzerzugriff aktiviert. "Ausgeschaltet" bedeutet: - Supportbenutzerzugriff wurde im Management Tenant global deaktiviert. - Kein Untermandanten-Benutzer hat derzeit einen aktiven Supportbenutzerzugriff (d. h. jede Supportbenutzeranfrage ist entweder abgelaufen oder wurde deaktiviert). |
| Anzahl aktiver Anfragen | Anzahl der aktuell aktiven Anfragen im Untermandanten. Wird nur angezeigt, wenn Supportbenutzerzugriff nicht global im Management Tenanteingeschaltet ist. Wird als Zahl in einem kleinen roten Punkt angezeigt. |
| Ablaufdatum | Legt das Datum fest, an dem der Supportbenutzerzugriff für den Mandanten abläuft. Wenn kein Datum festgelegt wurde, wird das Ablaufdatum auf "Unbegrenzt" gesetzt. |
Das Sperren eines Mandanten verhindert jeglichen Zugriff auf diesen Mandanten, unabhängig davon, ob der Zugriff über ein Gerät, einen Benutzer oder eine andere Anwendung erfolgt. Zudem sind alle seine Microservices nicht gestartet, und bei Reaktivierung des Mandanten werden alle seine Microservices neu gestartet.
Die Daten des Mandanten bleiben in der Datenbank und können später durch Klicken auf Einschalten wieder bereitgestellt werden.
Näheres zur Abrechnungsperspektive von gesperrten Mandanten finden Sie unter Nutzungsstatistiken und Abrechnung > Lebenszyklus.
Klicken Sie auf das Menüsymbol rechts im jeweiligen Untermandanten-Eintrag und anschließend auf Sperren.
Bestätigen Sie im darauf folgenden Dialog das Sperren, indem Sie OK klicken und Ihr Passwort eingeben.
Während des Sperrvorgangs wird eine E-Mail an den Administrator des Mandanten gesendet, wenn eine entsprechende E-Mail-Adresse konfiguriert ist.
Das Löschen eines Untermandanten kann nicht rückgängig gemacht werden. Deshalb ist diese Funktion aus Sicherheitsgründen nur im Management Tenant verfügbar. Mandanten können ausschließlich vom Management Tenant aus gelöscht werden.
Administratoren in Enterprise Tenants dürfen aktive Untermandanten nur sperren, aber nicht löschen.
Klicken Sie auf das Menüsymbol rechts im jeweiligen Untermandanten-Eintrag und anschließend auf Löschen, um einen Mandanten dauerhaft zu löschen und alle zugehörigen Daten zu entfernen.
In der Registerkarte Anwendungen können Sie alle für einen Mandanten abonnierten Anwendungen ansehen sowie Anwendungen für einen Mandanten abonnieren oder entfernen. Standardmäßig werden für einen Mandanten die Standardanwendungen von Cumulocity IoT abonniert.
Bewegen Sie den Mauszeiger über die unter Verfügbare Anwendungen auf der rechten Seite angezeigten Anwendungen und klicken Sie bei der gewünschten Anwendung auf Abonnieren.
Bewegen Sie den Mauszeiger über die unter Abonnierte Anwendungen auf der linken Seite angezeigten Anwendungen und klicken Sie bei der gewünschten Anwendung auf Abbestellen.
Für alle Anwendungen, die als Microservices von Cumulocity IoT gehostet werden, wird neben dem Namen einer der folgenden Microservice-Status als Symbol angezeigt:
Microservice ist in Betrieb
Microservice ist gestört
Microservice ist außer BetriebDetails zum Status können durch Ausklappen des jeweiligen Eintrags angezeigt werden.
Folgende Informationen werden angezeigt:
Weitere Details finden Sie in der Registerkarte Status der entsprechenden Anwendung, siehe Administration > Verwalten von Anwendungen.
Die Registerkarte Benutzerdefinierte Attribute ermöglicht Ihnen das Anzeigen und Bearbeiten von Werten von benutzerdefinierten Attributen, sowohl von vordefinierten (wie “Externe Referenz”) als auch denen, die in der Attributsbibliothek definiert sind. Solche Attribute werden auch als Spalten auf der Seite Nutzungsstatistiken angezeigt.
Plattformadministratoren können die Anfragerate jedes Untermandanten über die folgenden benutzerdefinierten Attribute begrenzen:
Die Anfragen-Begrenzungsfunktion wird erst aktiviert, wenn beide HTTP-Attribute (HTTP-Queue begrenzen und HTTP-Anfragen begrenzen) konfiguriert sind. Wird einer der Werte weggelassen, funktioniert es nicht.
Außerdem ist es möglich, die Größe des CEP-Puffers und des Data Broker-Puffers für einen Mandanten anzupassen. Dies kann mithilfe der folgenden benutzerdefinierten Untermandant-Fragmente vom Management Tenant aus durchgeführt werden:
Wenn keine Begrenzung auf Mandanten- und Systemebene vorliegt, wird die Begrenzungsfunktion als deaktiviert betrachtet und der Mandant erhält unbegrenzten Zugriff. Um die Begrenzung der Anfragerate wieder abzuschalten, setzen Sie den Wert auf “-1”.
Über das benutzerdefinierte Attribut “Geräteanzahl begrenzen” können Plattformadministratoren die Anzahl der gleichzeitig registrierten Hauptgeräte oder der registrierten Geräte insgesamt (einschließlich Kindgeräte) begrenzen.
Auf der Seite Nutzungsstatistiken können sie die Höchstanzahl registrierter Geräte bzw. Hauptgeräte sowie den Höchstwert des genutzten Datenspeichers einsehen.
Über das Kontrollkästchen Gainsight-Tracking aktivieren kann ein übergeordneter Mandant das Produkterfahrungs-Tracking über die Produkterfahrungssoftware Gainsight PX für den jeweiligen untergeordneten Mandanten aktivieren/deaktivieren.
Auf Mandantenebene kann das Produkterfahrungs-Tracking von Gainsight durch Deaktivieren des Cookie-Banners auf der Seite Branding ausgeschaltet werden, siehe Anpassen der Plattform > Branding.
Auch wenn Tracking für einen Mandanten aktiviert ist, müssen Benutzer aktiv das Tracking von funktionellen Cookies akzeptieren, damit funktionelle Daten zur Nutzung der Plattform verfolgt werden können, siehe Erste Schritte > Aufrufen und Anmelden an der Plattform.
Eine Mandantenregel ist eine Menge von Mandantenoptionen und Datenhaltungsregeln. Mandantenoptionen und Datenhaltungsregeln können während der Erstellung eines Mandanten konfiguriert werden.
Das Erstellen einer Mandantenregel mit bestimmten Optionen und Regeln spart Zeit bei der Erstellung verschiedener Mandanten mit den gleichen Einstellungen.
Klicken Sie auf Mandantenregeln im Menü Mandanten, um alle verfügbaren Mandantenregeln anzuzeigen.
Für jede Mandantenregel wird der Name, eine optionale Beschreibung und die Anzahl der Optionen und Datenhaltungsregeln angezeigt, wahlweise in Listen- oder Gitteransicht.
Die Mandantenregel wird der Mandantenregel-Liste hinzugefügt.
Klicken Sie auf den jeweiligen Regeleintrag oder auf das Menüsymbol rechts im Regeleintrag und anschließend auf Bearbeiten.
Nehmen Sie im darauf folgenden Dialog die gewünschten Änderungen vor und klicken Sie auf Speichern, um Ihre Einstellungen zu speichern.
Um eine Datenhaltungsregel oder eine Mandantenoption aus einer Regel zu entfernen, bewegen Sie den Mauszeiger darüber und klicken Sie auf das Löschen-Symbol.
Klicken Sie auf das Menüsymbol in dem Mandantenregel-Eintrag, den Sie duplizieren wollen, und klicken Sie dann auf Duplizieren.
Klicken Sie auf das Menüsymbol in dem Mandantenregel-Eintrag, den Sie löschen wollen, und klicken Sie dann auf Löschen.
In der Cumulocity IoT-Plattform können Sie konfigurieren, welche Anwendungen und Microservices bei der Erstellung eines Mandanten für diesen abonniert sind. Wenn Sie einen neuen Mandanten erstellen, werden die angegebenen Anwendungen und Microservices automatisch für ihn abonniert.
Zusätzlich können Sie festlegen, welche Anwendungen und Microservices für einen Mandanten abonniert werden, wenn ein System-Upgrade durchgeführt wird. Diese Liste kann von den Standardabonnements bei der Mandantenerstellung abweichen. Beispielsweise könnten bestimmte Standardanwendungen für einen Mandanten nach der Erstellung abbestellt worden sein und Sie wollen nicht, dass diese Anwendungen erneut für ihn abonniert werden, oder Sie möchten andere Anwendungen für ihn abonnieren.
Auf der Seite Standardabonnements können Sie zwei separate Listen von Anwendungen konfigurieren: Diese werden standardmäßig abonniert für:
Links wird die Liste der abonnierbaren Anwendungen (Web-Anwendungen und Microservices) angezeigt. Sie umfasst:
Rechts sehen Sie die Spalten Zum Zeitpunkt der Mandantenerstellung abonniert und Plattform-Upgrade abonniert.
Anfänglich zeigen die Listen die aus der Mandantenhierarchie geerbten Standardabonnements.
Sie können beide Listen außer Kraft setzen, indem Sie den entsprechenden Umschalter betätigen. Dadurch werden alle verfügbaren Anwendungen sichtbar (anfänglich sind nicht ausgewählte Anwendungen ausgeblendet), doch die Auswahl bleibt unverändert.
Als Nächstes passen Sie die Listen nach Ihren Bedürfnissen an, indem Sie zusätzliche Anwendungen auswählen, die standardmäßig abonniert werden sollen, oder Anwendungen abwählen, die nicht abonniert werden sollen.
Sie können auch alle abwählen, wenn Sie nicht möchten, dass bei einer Mandantenerstellung bzw. einem Plattform-Upgrade Abonnements getätigt werden.
Wenn Sie zu den von der Mandantenhierarchie geerbten Einstellungen zurückkehren möchten, betätigen Sie einfach erneut den Umschalter.
Speichern Sie die Einstellungen, indem Sie unten auf der Seite auf Speichern klicken.
Die Standardabonnements können Sie für Untermandanten außer Kraft setzen, indem Sie eine Mandantenregel mit den folgenden Optionen einrichten:
Mit Benutzerhierarchien können Sie verschiedene Organisationen in Cumulocity IoT verwalten, die dennoch dieselbe Datenbank teilen. Diese Organisationen können eingeschränkten Zugriff auf eine Untermenge der geteilten Daten haben und ihre eigenen untergeordneten Benutzer verwalten.
Auf der Seite Benutzer werden Benutzerhierarchien durch einen Pfeil links vom Benutzer-Symbol angezeigt. Klicken Sie auf diesen Pfeil, um die Benutzerhierarchie auszuklappen. Sie können auch alle Benutzerhierarchien gleichzeitig anzeigen oder verbergen, indem Sie Alle ausklappen bzw. Alle einklappen rechts in der oberen Menüleiste klicken.
Eine kleine Zahl neben dem Benutzernamen zeigt an, wieviele direkt untergeordnete Benutzer ein Benutzer hat. Untergeordnete Benutzer sind Benutzer, die von ihrem übergeordneten Benutzer verwaltet werden können und die maximal die Berechtigungen des übergeordneten Benutzers haben können. Im Beispiel unten hat der Benutzer “Demo user” zwei direkt untergeordnete Benutzer.
Benutzerhierarchien werden erstellt, indem einem Benutzer ein “Besitzer” zugewiesen wird. Dieser Besitzer kann den Benutzer verwalten. Der Benutzer kann maximal die Berechtigungen des Besitzers haben.
Wenn Sie einen neuen Benutzer erstellen, wird der Besitzer automatisch auf den Benutzer gesetzt, der angemeldet ist, sofern der angemeldete Benutzer nur die “Benutzerverwaltung”-Berechtigung ERSTELLEN hat. Der Besitzer kann später geändert werden, jedoch nur durch einen Benutzer mit der “Benutzerverwaltung”-Berechtigung ADMIN.
Wenn Sie möchten, dass ein Besitzer nur seine untergeordneten Benutzer verwalten kann, stellen Sie sicher, dass der Besitzer keine globale Rolle mit der “Benutzerverwaltung”-Berechtigung für alle Benutzer hat.
Beispiel
Ein Benutzer A hat die Rolle “business”. Benutzer A wird zum Besitzer eines neuen Benutzers B. Dem Benutzer B kann dann nur eine business-Rolle zugewiesen werden (und nicht etwa eine admin-Rolle), da der Benutzer keine höhere Berechtigung haben kann als der Besitzer. Wenn Sie versuchen, Benutzer B eine andere Rolle als “business” zuzuweisen, so ist die Rolle für ein Abonnement nicht verfügbar und wird mit einem Warnsymbol und dem Hinweis versehen, dass diese Operation nicht zulässig ist.
In Cumulocity IoT kann ein Benutzer seine Benutzerhierarchien und Berechtigungen einem anderen Benutzer übertragen (beide Benutzer müssen derselben Hierarchie angehören). Der Benutzer, dem die Berechtigungen übertragen werden, hat die gleichen Benutzerverwaltungsrechte wie der Benutzer, der die Übertragung aktiviert hat. Zur Durchführung der Benutzerverwaltung muss der delegierte Benutzer die Berechtigung USER_MANAGEMENT_CREATE haben oder eine der vordefinierten Rollen verwenden: “Geteilter Benutzermanager”, “Benutzerverwaltung”.
Sie können Berechtigungen auch temporär übertragen, wenn Sie etwa zeitweilig nicht verfügbar sind.
Öffnen Sie entweder den Benutzer und klicken Sie auf das Delegieren-Symbol im Feld Delegiert von oder öffnen Sie das Kontextmenü über das Menüsymbol rechts vom Benutzer und wählen Sie Delegieren.
Entfernen Sie die Delegierung im Feld Delegiert von oder klicken Sie auf das Menüsymbol rechts neben dem Benutzereintrag in der Benutzerliste und wählen Sie Delegierung aufheben aus dem Kontextmenü.
Wenn der Benutzer, dem Sie die Berechtigungen übertragen haben, auch bestimmte Geräte verwalten können soll, muss der Admin-Benutzer diesem Benutzer die Berechtigung für die entsprechenden Geräte (Stammdatenrollen) direkt zuweisen. Dies kann über den Befehl Stammdatenrollen eines anderen Benutzers kopieren erfolgen. Weitere Informationen finden Sie unter Zuweisen von Stammdatenrollen.
Im folgenden Beispiel kann der Benutzer nicht den Zugriff auf die “Administration”-Anwendung ändern, da der Besitzer des Benutzers keine Berechtigung “Benutzerverwaltung” hat. Daher kann der Besitzer keinen Zugriff auf integrierte Anwendungen erteilen.
Mit dem Enterprise Tenant von Cumulocity IoT können Sie verschiedene Aspekte Ihrer Plattform individuell nach Ihren Bedürfnissen anpassen.
Neben verschiedenen Konfigurationseinstellungen können Sie auch Ihr eigenes Branding und Ihren eigenen Domain-Namen verwenden.
Klicken Sie auf Enterprise Tenant im Menü Einstellungen, um zu diesen Einstellungen zu gelangen.
Die folgenden Platzhalter sind in der Registerkarte Konfiguration zu finden:
| Platzhalter | Beschreibung |
|---|---|
| {host} | Der Wert dieses Platzhalters ist “https://” + “<<tenantId>>” + “<<base-domain>>”. Beispiel: Wenn “tenantId” automatisch generiert wird, ist der Host https://t12345678.cumulocity.com. |
| {tenant-domain} | Dies ist der Standort, an dem der Mandant aufgerufen werden kann. Entspricht “https://” + “<<tenantDomainName>>”. Beispiel: {tenant-domain} kann https://myTenant.cumulocity.com sein. Bei einem Enterprise Tenant können die {tenantDomain}-Platzhalter verschiedene Werte annehmen. Ein Beispiel für eine Mandanten-Domain (tenant-domain) wäre https://myTenant.myhost.com. |
| {token} | Ein automatisch generiertes System-Token zum Zurücksetzen des Passworts. Wenn ein Benutzer das Zurücksetzen des Passworts anfordert, wird ein neues zufallsgeneriertes Token erstellt. Dieses Token ist nur mit dem jeweiligen Benutzer verknüpft und ermöglicht nur ein einmaliges Zurücksetzen des Passworts. Dieser Platzhalter wird standardmäßig in Verbindung mit dem Attribut {tenant-domain} verwendet: “{tenant-domain}?token={token}”. |
| {email} | Dieser Platzhalter wird durch die E-Mail-Adresse des empfangenden Benutzer ersetzt, die in den Benutzereinstellungen gespeichert ist. Einige Ansichten der Benutzeroberfläche erkennen diesen Parameter und fügen den Wert vorab in das entsprechende Feld ein, z. B. beim Zurücksetzen des Passworts. |
Unter Zwei-Faktor-Authentifizierung können Sie das SMS-Template, das an die Benutzer geschickt wird, ändern.
Im Bereich Support-Link können Sie eine URL eingeben, die als Link zu einer Support-Seite verwendet wird. Wenn Sie hier keinen Link bereitstellen, wird der Standardlink zur Tech Community-Seite verwendet.
Geben Sie “false” ein, um den Link zu verbergen.
Im Bereich Passwort zurücksetzen können Sie alle Einstellungen im Zusammenhang mit E-Mail-Templates zum Zurücksetzen des Passworts ändern.
Ganz oben können Sie festlegen, ob Sie zulassen möchten, E-Mails an unbekannte E-Mail-Adressen zu senden.
Stellen Sie im Feld E-Mail-Template für das Zurücksetzen von Passwörtern ein Template bereit, das verwendet werden soll, wenn die Adresse bekannt ist, und eine für unbekannte Adressen. Der Link zum Zurücksetzen des Passworts kann beispielsweise lauten: {tenant-domain}/apps/devicemanagement/index.html?token={token}&email={email}.
Geben Sie im Feld E-Mail-Betreff ein Betreff für alle E-Mails im Zusammenhang mit dem Zurücksetzen des Passworts ein.
Geben Sie in den folgenden beiden Feldern jeweils ein Template für die E-Mails zur Bestätigung der Passwortänderung und für die Einladung zur Aktivierung ein.
Im Bereich E-Mail-Server können Sie benutzerdefinierte E-Mail-Server-Einstellungen konfigurieren.
Wählen Sie im Feld Protokoll und Verschlüsselung einen Protokoll-/Verschlüsselungstyp aus der Auswahlliste. Hierbei kann es sich um einen der folgenden Typen handeln:
Geben Sie Host, Port, Benutzername, Passwort und Senderadresse für den E-Mail-Server an. Die leere Passwortkonfiguration wird für den Enterprise Tenant unterstützt.
Im Bereich Datenexport können Sie den E-Mail-Betreff und das E-Mail-Template für den Datenexport angeben sowie die Fehlermeldung, wenn Benutzer nicht autorisiert ist definieren.
Im Bereich Speicherbegrenzung können Sie den E-Mail-Betreff und das E-Mail-Template für E-Mails festlegen, die gesendet werden, bevor Daten bei Überschreitung der Speicherbegrenzung gelöscht werden (Warnung) und nachdem Daten gelöscht wurden (Begrenzung überschritten).
Im Bereich Mandanten werden gesperrt können Sie Einstellungen für E-Mails vornehmen, die gesendet werden, wenn ein Mandant gesperrt wurde.
Oben können Sie auswählen, ob Sie die E-Mail zum Administrator des gesperrten Mandanten senden möchten und einen weiteren E-Mail-Empfänger angeben. Unten definieren Sie den Betreff und die Vorlage für die E-Mail “Gesperrter Benutzer”.
Klicken Sie unten auf Konfiguration speichern, um Ihre Eingaben zu speichern.
Mit der Branding-Funktion können Sie das Erscheinungsbild der Benutzeroberfläche für Ihre Mandanten nach Ihren Vorlieben gestalten.
In der Registerkarte Branding können Sie verschiedene Parameter wie Logos, Farben und Schriftarten konfigurieren, die auf der gesamten Plattform verwendet werden.
Die Parameter werden auf der linken Seite der Registerkarte konfiguriert, während Sie auf der rechten Seite in einer Vorschau sehen können, wie sich Ihre Auswahl auswirkt.
Für eine detailliertere Vorschau Ihrer Einstellungen klicken Sie in der oberen Menüleiste auf Vorschau anzeigen, um das Erscheinungsbild Ihrer Branding-Einstellungen in der gesamten Plattform zu überprüfen. In der Vorschau können Sie interagieren und sogar zwischen verschiedenen Anwendungen wechseln. Jede Änderung, die Sie in der Registerkarte Branding vornehmen, wird sofort auf die Seite Vorschau angewendet.
Wenn Sie fertig sind oder Ihre Einstellungen speichern möchten, klicken Sie am unteren Rand des Bereichs Konfiguration auf Speichern, um Ihre Branding-Einstellungen in Ihrem Mandanten zu speichern.
Durch Speichern werden die Einstellungen noch nicht auf den aktuellen Mandanten und die entsprechenden Untermandanten angewendet. Um dies zu bewirken, klicken Sie in der oberen Menüleiste auf Anwenden.
Klicken Sie in der oberen Menüleiste auf Zurücksetzen, um das Branding des aktuellen Mandanten und seiner Untermandanten auf die Standardeinstellungen zurückzusetzen. Die benutzerdefinierten Einstellungen werden weiterhin gespeichert, aber nicht mehr angewendet.
Unter “Konfiguration” können die folgenden Branding-Parameter konfiguriert werden.
Allgemein
Im Bereich Allgemein können Sie den Titel bearbeiten, der im Browser-Tab verwendet wird.
Hauptlogo
Unter Hauptlogo können Sie die folgenden Elemente definieren:
Navigatorlogo
Unter Navigatorlogo können Sie das Logo, das oben im Navigator angezeigt wird, bereitstellen und die Höhe für das Navigatorlogo einstellen.
Schriftart
Im Bereich Schriftart definieren Sie die Schriftarten für Ihre Branding-Version.
Sie können den Basis-Schriftartenstapel und den Überschriften-Schriftartenstapel auswählen sowie eine Option für den Navigator-Schriftartenstapel (entweder identisch mit Basis- oder Überschriftenschriftart). Sie können außerdem einen Link auf externe Schriftarten setzen, die Sie verwenden möchten.
Farben
Im Bereich Farben definieren Sie die Farben für Ihre Branding-Version.
Die folgenden Parameter können definiert werden (Werte in hex, rgb oder rgba):
Obere Leiste
Unter Obere Leiste definieren Sie die Parameter für die obere Leiste.
Die folgenden Parameter können definiert werden (Werte in hex, rgb oder rgba):
Navigator
Unter Navigator definieren Sie die Parameter für den Navigator.
Die folgenden Parameter können definiert werden (Werte in hex, rgb oder rgba):
Sonstiges
Im Bereich Sonstiges legen Sie den “Rand-Radius für Schaltflächen” durch Angabe eines Werts in Pixel (px) fest.
Cookie-Banner
Im Abschnitt Cookie-Banner legen Sie die Einstellungen für das Banner mit den Cookie-Nutzungsinformationen fest. Sofern es hier nicht deaktiviert ist, wird das Banner für alle Benutzer des aktuellen Mandanten und aller Untermandanten angezeigt, bis ein Benutzer auf Akzeptieren und fortfahren klickt.
Durch Deaktivieren des Cookie-Banners wird auch das Produkterfahrungs-Tracking von Gainsight für den aktuellen Mandanten und alle seine Untermandanten deaktiviert.
Folgende Parameter können festgelegt werden:
Ein entscheidendes Merkmal des Enterprise Tenant ist die Fähigkeit, die Cumulocity IoT-Plattform mit einem benutzerdefinierten Domain-Namen zu betreiben. Dies bedeutet, dass Sie die Plattform so konfigurieren können, dass sie Ihnen und Ihren Kunden mit einem Hostnamen Ihrer Wahl dient, z. B. mit *.iot.mycompany.com anstelle der Standard-URL von Cumulocity IoT. Zudem haben Sie die Möglichkeit, Untermandanten mit Ihrer Domain zu erstellen. Diese verwenden dann <subtenantName>.iot.mycompany.com als ihren Hostnamen.
Für die Verwendung einer benutzerdefinierten Domain gelten drei Voraussetzungen:
Ein SSL-Zertifikat muss die folgenden Kriterien erfüllen, um mit der Enterprise Tenant-Funktion verwendet werden zu können:
Cumulocity IoT unterstützt ein Einzelzertifikat, das durch die Stammzertifizierungsstelle signiert ist, sowie ein Vollkettenzertifikat, das ein oder mehrere Zwischenzertifikate enthält.
Um ein SSL-Zertifikat mit Cumulocity IoT verwenden zu können, muss das Zertifikat zusammen mit seinem privaten Schlüssel in einer einzelnen Datei im Dateiformat PKCS #12 an die Plattform hochgeladen werden.
Die meisten Zertifizierungsstellen liefern ihre Zertifikate und zugehörigen privaten Schlüssel im Dateiformat PEM, wobei zwei separate Textdateien verwendet werden: eine für die Zertifikatkette und eine für den privaten Schlüssel. Vergewissern Sie sich, dass der private Schlüssel nicht durch ein Passwort oder eine Passphrase geschützt ist.
Solche PEM-Dateien lassen sich mittels OpenSSL leicht in das Format #PKCS #12 umverpacken. Im folgenden Beispiel dient OpenSSL zum Zusammenführen einer Zertifikatkette (chain.cert) und des entsprechenden Schlüssels (privkey.pem) zu einer PKCS #12-Keystore-Datei (out_keystore.p12), die mit Cumulocity IoT verwendet werden kann.
openssl pkcs12 -export -out out_keystore.p12 -inkey privkey.pem -in cert.pem -certfile chain.pem
Die DNS-Einträge für Ihre benutzerdefinierte Domain müssen so konfiguriert werden, dass alle Anfragen an die Cumulocity IoT-Plattform geleitet werden.
Wir empfehlen dringend, zu diesem Zweck den Wildcard-Eintrag CNAME zu verwenden. Der CNAME muss Ihre Wildcard-Domain aus dem Zertifikat im Feld NAME enthalten. Das Feld VALUE des CNAME-Eintrags muss auf den Hostnamen von Cumulocity IoTverweisen. Dieser Ziel-Hostname lässt sich leicht anhand Ihrer aktuellen Mandanten-URL ermitteln. Wenn Ihre Mandanten-URL http://mytenant.cumulocity.com lautet, ist der Ziel-Hostname mytenant.cumulocity.com. Achten Sie außerdem darauf, eventuell miteinander in Konflikt stehende A-Einträge zu löschen.
Beispiel:
Wenn Sie *.iot.mycompany.com für Ihre Enterprise-Untermandanten verwenden möchten und Cumulocity IoT unter mytenant.cumulocity.com verwenden, muss der folgende CNAME-Eintrag zu Ihrer DNS-Zone hinzugefügt werden:
NAME TYPE VALUE
----------------------------------------------------
*.iot.mycompany.com. CNAME mytenant.cumulocity.com.
Aus folgenden Gründen raten wir dringend von der Verwendung alternativer DNS-Konfigurationen ab:
Sobald die DNS-Konfiguration vorliegt und ein Zertifikat gemäß den entsprechenden Anforderungen verfügbar ist, kann dieses problemlos an die Plattform hochgeladen werden.
Klicken Sie in der Registerkarte Domain-Name auf der Seite Enterprise Tenant auf Zertifikat hochladen. Wählen Sie das Zertifikat in Ihrem Dateisystem aus und klicken Sie auf Hochladen.
Anschließend können Sie die Domain durch einen einzigen Mausklick auf den Domainnamen aktivieren. Nachdem die Domain aktiviert wurde, werden Sie über den neuen Domain-Namen zu Ihrem Enterprise Tenant umgeleitet. Sie erhalten eine E-Mail mit Informationen über die Aktivierung. Beachten Sie, dass der Domain-Name Ihres Management Tenant statisch ist. Beispiel: Wenn Ihre Wildcard-Domain “* .iot.mycompany.com” ist, lautet die Domain des Management Tenant “management.iot.mycompany.com”.
Wenn Ihr Zertifikat abläuft, müssen Sie es durch ein neues Zertifikat mit einer längeren Gültigkeitsdauer aktualisieren. Wenn Sie das Zertifikat aktualisieren, stellen Sie sicher, dass das Zertifikat folgende Anforderungen erfüllt:
Wenn Sie zu Ihrer alten Domain auf Cumulocity IoT zurückkehren möchten, können Sie Ihr Zertifikat ganz einfach wieder deaktivieren.
Für den Fall, dass Sie Cumulocity IoT mit Ihrer eigenen Domain nicht erreichen können, empfehlen wir Ihnen, zunächst die folgenden Überprüfungen durchzuführen, um Ihre DNS-Einstellungen zu verifizieren.
Prüfen, ob der DNS-Eintrag korrekt ist
Führen Sie folgendes Kommando aus:
host management.<Ihr Domain-Name>
Es sollte das folgende Ergebnis angezeigt werden:
management.<ihr domain name> ist ein Alias für <Instanz-Domain-Name>
<Instanz-Domain-Name> hat die Adresse <IP-Adresse>
Prüfen, ob die API antwortet
Führen Sie folgendes Kommando aus:
curl -v -u '<Mandanten-ID>/<ihr benutzer>:<ihr password>' --head http://management.<ihr domain name>/inventory/managedObjects
Es sollte das folgende Ergebnis angezeigt werden:
...
HTTP/1.1 200 OK
...
Die Funktion “Supportbenutzerzugriff” gibt den Anbietern der Cumulocity IoT-Plattform (im Falle von Public-Cloud-Instanzen die Software AG und im Falle von individuellen lokalen Installationen der jeweilige Service-Provider) die Möglichkeit, ihre Kunden zu unterstützen, indem sie über einen Supportbenutzer auf deren Benutzer zugreifen. Ein Supportbenutzer ist ein Benutzer im Management Tenant mit spezifischen Berechtigungen, nämlich für den Zugriff auf Untermandanten-Benutzer im Falle von Problemen.
Zur Nutzung dieser Funktion muss Supportbenutzerzugriff konfiguriert sein und die erforderlichen Supportbenutzer müssen im Management Tenant erstellt sein, siehe Administration > Plattform-Konfigurationseinstellungen > Supportbenutzer.
Supportbenutzerzugriff kann entweder:
Dies wird global im Management Tenant konfiguriert, siehe Administration > Plattform-Konfigurationseinstellungen > Supportbenutzer.
Bei globaler Aktivierung kann sich der Supportbenutzer bei allen zulässigen Untermandanten als beliebiger Benutzer uneingeschränkt anmelden.
Bei globaler Deaktivierung kann der Supportbenutzerzugriff bei Bedarf immer noch durch einen Untermandanten-Benutzer eingeschaltet werden. Dies erfolgt durch Klicken auf Support aktivieren im Menü Benutzer, siehe Erste Schritte > Benutzeroptionen und -einstellungen. Der Supportzugriff ist nicht auf den Benutzer beschränkt, der ihn aktiviert hat, sondern gilt für alle Benutzer des Mandanten. Dies ist notwendig, um Probleme mit Rollen/Rechten nachvollziehen zu können.
Nachdem ein Benutzer den Supportzugriff aktiviert hat, ändert sich der Menüpunkt auf Support deaktivieren, so dass der Benutzer eine ausstehende Supportanfrage deaktivieren kann, die sich erübrigt hat, bevor sie abläuft.
Wenn die Schaltfläche Support aktivieren oder Support deaktivieren im Menü Benutzer nicht zu sehen ist, wurde der Supportbenutzerzugriff global aktiviert. Weitere Details erfragen Sie bitte beim Produkt-Support.
Wenn ein Benutzer mit Mandanten-Admin-Berechtigungen die Supportanfrage deaktiviert, werden alle Supportanfragen für den Mandanten deaktiviert.
Die Dauer der aktiven Supportanfrage kann im Management Tenant global konfiguriert werden (der Standardwert ist 24 Stunden), siehe Administration > Plattform-Konfigurationseinstellungen.
Jede neue Supportanfrage verlängert die Supportdauer um die angegebene Anzahl von Stunden. Nachdem die letzte Supportanfrage in einem Untermandanten abgelaufen ist oder vom Benutzer aktiv deaktiviert wurde, wird der Supportbenutzerzugriff für den Untermandanten sofort deaktiviert (sofern er nicht global aktiviert ist).
Details zum Status von Supportanfragen und Supportbenutzerzugriff für einen Mandanten finden Sie in der Registerkarte Attribute des Mandanten, siehe Verwalten von Mandanten.
Um sich vom Management Tenant aus als Supportbenutzer anzumelden, müssen Sie im Login-Bildschirm folgende Informationen eingeben:
“Supportbenutzer” und “Benutzer” sind in folgender Schreibweise in das Feld Benutzername einzugeben:
<support user>$<user>
Beispiel
Nehmen wir an, Sie erhalten eine Supportanfrage von einem Benutzer “John” im Mandanten testtenant.cumulocity.com (mit der Mandanten-ID t07007007). Ihr Benutzername im Management Tenant ist “Jill” und Sie haben die Berechtigung, Support für testtenant.cumulocity.com zu leisten. In diesem Fall können Sie sich mit den folgenden Zugangsdaten anmelden, um zu reproduzieren, was John sieht:
Alternativ können Sie “<support user>$” im Feld Benutzername eingeben, um mit einem der Administrationsbenutzer auf den Mandanten zuzugreifen.
Audit-Logs werden für jeden Zugriff eines Supportbenutzers erstellt sowie für jede ausgeführte Aktion. In der Spalte “Wer?” wird der Name des Autors folgendermaßen angezeigt: “support_user$user”.
Der Management Tenant kann die Lizenzen für die Domains der Enterprise Tenants über die Benutzeroberfläche verwalten.
Die Lizenz wird validiert und den Mandantenoptionen hinzugefügt.
Die Seite Nutzungsstatistiken zeigt statistische Informationen für jeden Untermandanten an.
Die folgenden Informationen werden für jeden Untermandanten bereitgestellt (im Screenshot oben aus Platzgründen nicht vollständig zu sehen):
| Feld | Beschreibung |
|---|---|
| ID | ID des Untermandanten |
| Name | Name des Untermandanten |
| API-Anfragen | Gesamtanzahl der API-Anfragen, einschließlich Anfragen von Geräten und Anwendungen |
| API-Anfrage von Geräten | Anzahl der API-Anfragen von Geräten |
| Speicherplatz (MB) | Gespeicherte Daten in Ihrem Konto |
| Höchstwert Speicher (MB) | Höchstwert der Speicherung |
| Hauptgeräte | Anzahl der Geräte ohne Kindgeräte |
| Höchstwert Hauptgeräte | Höchstanzahl Hauptgeräte, ohne Kindgeräte |
| Geräte | Die Gesamtanzahl der mit dem Untermandanten verbundenen Geräte |
| Höchstwert Geräte | Höchstanzahl Geräte, einschließlich Kindgeräte |
| Endpunktgeräte | Blattgeräte (ohne Gateways und Kinder) |
| Abonnierte Anwendungen | Anzahl der vom Untermandanten abonnierten Anwendungen |
| Erstellungszeitpunkt | Datum und Zeit der Erstellung des Untermandanten |
| Erzeugte Alarme | Anzahl der erzeugten Alarme |
| Aktualisierte Alarme | Anzahl der aktualisierten Alarme |
| Erstellte Stammdaten | Anzahl der erstellten Managed Objects |
| Aktualisierte Stammdaten | Anzahl der aktualisierten Managed Objects |
| Erstellte Ereignisse | Anzahl der erstellten Ereignisse |
| Aktualisierte Ereignisse | Anzahl der aktualisierten Ereignisse |
| Erstellte Messwerte | Anzahl der erstellten Messwerte |
| Gesamt Inbound-Transfer | Summe aller Inbound-Transfers (erzeugte Alarme, aktualisierte Alarme, erstellte Ereignisse, aktualisierte Ereignisse, erstellte Stammdaten, aktualisierte Stammdaten, erstellte Messwerte). |
| CPU (m) | Microservice-CPU-Nutzung, angegeben in CPU-Millisekunden, weitere Informationen siehe Microservice-Nutzung |
| Speicher (MB) | Microservice-Speichernutzung, weitere Informationen siehe Microservice-Nutzung |
| Übergeordneter Mandant | Name des übergeordneten Mandanten (nur verfügbar für den Management Tenant) |
| Externe Referenz | Dieses Feld ist für den individuellen Gebrauch. Sie können hier beispielsweise einen Link zum CRM-System oder eine interne Kundennummer einfügen. |
Außerdem werden benutzerdefinierte Attribute angezeigt, falls vorhanden.
Benutzerdefinierte Attribute können in der Attributsbibliothek definiert werden. Anschließend können entsprechende Werte in der Registerkarte Benutzerdefinierte Attribute des Mandanten eingestellt werden.
Sie können die Liste der Nutzungsstatistiken nach einem bestimmten Zeitraum filtern, indem Sie einen Start- und einen Endzeitpunkt in der oberen Menüleiste eingeben und Filter klicken. Die Seite Nutzungsstatistiken zeigt die Zahlen für alle Untermandanten in diesem Zeitraum an.
Sie können außerdem die Liste nach jeder Spalte filtern und sortieren, indem Sie auf das Filtersymbol neben dem Namen der entsprechenden Spalte klicken und die Filterkriterien eingeben. Siehe auch Erste Schritte > Eigenschaften und Funktionen der Benutzeroberfläche > Filtern.
Die CSV-Datei wird in Ihr Dateisystem heruntergeladen.
Die Funktion Microservice-Nutzung sammelt Informationen über die Ressourcennutzung je Untermandant für jeden Microservice. So können Enterprise Tenants und Service Provider die Gebühren für Mandanten nicht nur auf Basis von Abonnements, sondern auch auf Basis der Ressourcennutzung berechnen.
Cumulocity IoT bietet zwei Abrechnungsmodi:
Abonnementbasierte Abrechnung - berechnet einen Festpreis, wenn ein Mandant einen Microservice abonniert hat, während die Ressourcennutzung dem Eigentümer zugewiesen wird.
Ressourcenbasierte Abrechnung - legt die Menge der von einem Microservice genutzten Ressourcen offen, um die Gebühr zu berechnen.
Die Abrechnungsmodi werden pro Microservice im Microservice-Manifest angegeben und im Feld “billingMode” festgelegt.
RESOURCES: Legt den ressourcenbasierten Abrechnungsmodus fest. Dies ist der Standardmodus. Er wird auf alle Microservices angewendet, für die nicht explizit der abonnementbasierte Abrechnungsmodus festgelegt wurde.
SUBSCRIPTION: Legt den abonnementbasierten Abrechnungsmodus fest.
Bei Microservices wird zwischen zwei Isolationsstufen unterschieden: Isolation nach Mandant und Isolation mehrerer Mandanten.
Bei abonnementbasierter Abrechnung wird die gesamte Ressourcennutzung unabhängig von der Isolationsstufe stets dem Microservice-Eigentümer zugewiesen, während dem abonnierenden Mandanten das Abonnement in Rechnung gestellt wird.
Bei ressourcenbasierter Abrechnung hängt die Berechnung von der Isolationsstufe ab:
Im Falle der Mehrmandanten-Isolationsstufe werden dem Eigentümer eines Microservice (z. B. der Management Tenant eines Management Tenant oder Service Providers) die genutzten Ressourcen der Untermandanten in Rechnung gestellt. Die Gebühren der Untermandanten sollten auf Basis des Abonnements gemäß der Vereinbarung zwischen dem Microservice-Eigentümer und dem abonnierten Mandanten berechnet werden. Die Liste der abonnierten Anwendungen ist als Teil der Mandantenanwendungen als subscribedApplications verfügbar.
| Abrechnungsmodus | Microservice-Isolation | Ressourcennutzung zugewiesen zu |
|---|---|---|
| Abonnementbasiert | Per-tenant | Eigentümer |
| Abonnementbasiert | Multi-tenant | Eigentümer |
| Ressourcenbasiert | Per-tenant | Abonnent |
| Ressourcenbasiert | Multi-tenant | Eigentümer |
Die folgenden Werte werden täglich bei jedem Mandanten erfasst:
Microservice-Ressourcen werden täglich anhand von Grenzwerten erfasst, die im Microservice-Manifest definiert sind. Am Ende jedes Tages werden die Informationen zur Ressourcennutzung in den Mandantenstatistiken erfasst. Es wird auch berücksichtigt, dass ein Microservice eventuell nicht für einen ganzen Tag abonniert wird.
Beispiel: Wenn ein Mandant einen Microservice 12 Stunden lang abonniert hat und der Microservice 4 CPUs und 4 GB Speicher aufweist, ist dies als 2000 CPU-Millisekunden und 2048 MB Speicher zu zählen.
Für Abrechnungszwecke wird zusätzlich zur CPU- und Speichernutzung die Ursache der Abrechnung erfasst (z. B. Eigentümer, Abonnement für Mandanten):
{
"name": "cep",
"cpu": 6000,
"memory": "20000",
"cause": "Owner"
},
{
"name": "cep-small",
"cpu": 1000,
"memory": "2000",
"cause": "Subscription for tenant"
}
Die Informationen über die Microservice-Nutzung werden auf der Seite Nutzungsstatistiken aufgeführt.
Näheres hierzu finden Sie unter Tenants in der Cumulocity IoT OpenAPI Specification. Beachten Sie, dass Detailinformationen nur bezüglich der täglichen Nutzung verfügbar sind. Bei einer zusammenfassenden Anfrage wird nur die Summe aller ausgegebenen Anfragen zurückgegeben.
Die automatische Skalierung überwacht Ihre Microservices und passt automatisch die Kapazität an, um eine stetige, prognostizierbare Leistung zu geringstmöglichen Kosten aufrechtzuerhalten. Die Microservice-Skalierung lässt sich durch Festlegen des Attributs scale im Microservice-Manifest leicht konfigurieren.
Wenn Sie beispielsweise einen Microservice haben, dessen Skalierungsregel auf AUTO gesetzt ist und der über die notwendigen CPU-Nutzungspunkte zum Starten einer neuen Microservice-Instanz für drei Stunden verfügt, wird Folgendes abgerechnet: (24/24 + 3/24) * verbrauchte Ressourcen.
Beachten Sie, dass für jede Änderung der Anzahl der Instanzen ein Auditeintrag vorgenommen wird.
Näheres hierzu finden Sie unter Audits in der Cumulocity IoT OpenAPI Specification.
Die Mandanten-Nutzungsstatistiken werden täglich entsprechend dem durch die Zeitzone des Servers bestimmten Beginn des Tages (BOD) und Ende des Tages (EOD) erfasst. Wenn die lokale Zeitzone eines Benutzers nicht mit der Zeitzone des Servers übereinstimmt, kann folglich eine vom Benutzer gestartete Operation je nach Serverzeit einem anderen Tag zugewiesen werden.
| Gerät | Server | |
|---|---|---|
| Zeitzone | CEST +2h | UTC |
| Zeitpunkt Messwerterzeugung | 26.08.2020T01:30:00+02:00 | 25.08.2020T23:30:00Z |
Ergebnis:
Die Anfrage wird für den 25.08.2020 in Rechnung gestellt, da sie laut Serverzeit dann eingereicht wurde.
| Gerät | Server | |
|---|---|---|
| Zeitzone | UTC | UTC |
| Zeitpunkt Messwerterzeugung | 26.08.2020T01:30:00Z | 26.08.2020T01:30:00Z |
Ergebnis:
Die Anfrage wird für den 26.08.2020 in Rechnung gestellt, da die Serverzeit mit der Gerätezeit übereinstimmt.
| Benutzer | Server | |
|---|---|---|
| Zeitzone | CEST +2h | UTC |
| Zeitpunkt Abonnement | 26.08.2020T12:00:00+02:00 | 26.08.2020T10:00:00Z |
| Zeitpunkt Abbestellung | 27.08.2020T12:00:00+02:00 | 27.08.2020T10:00:00Z |
Ergebnis:
Die Ressourcen werden hauptsächlich dem 26.08.2020 zugewiesen, da der Microservice gemäß UTC-Zeitzone an diesem Tag 14 Stunden und am darauf folgenden Tag 10 Stunden aktiv war. Dies entspricht möglicherweise nicht den Erwartungen des Benutzers, aus dessen Sicht der Microservice täglich 12 Stunden aktiv war.
| Benutzer | Server | |
|---|---|---|
| Zeitzone | KI +14h (Kiribati) | UTC |
| Zeitpunkt Abonnement | 26.08.2020T12:00:00+14:00 | 25.08.2020T22:00:00Z |
| Zeitpunkt Abbestellung | 26.08.2020T20:00:00+14:00 | 26.08.2020T06:00:00Z |
Ergebnis:
Aus Sicht des Benutzers wurde der Microservice am 26.08.2020 für 8 Stunden abonniert. In Serverzeit waren es jedoch 2 Stunden vor Ende des Tages (EOD) am 25.08.2020 und 6 Stunden nach Beginn des Tages (BOD) am 26.08.2020.
| Benutzer | Server | |
|---|---|---|
| Zeitzone | CEST | AS -11h (Amerikanisch-Samoa) |
| Zeitpunkt Abonnement | 26.08.2020T12:30:00+2:00 | 25.08.2020T23:30:00Z |
| Zeitpunkt Abbestellung | 26.08.2020T13:00:00+2:00 | 25.08.2020T24:00:00Z |
Ergebnis:
In diesem Fall haben wir einen großen Zeitunterschied zwischen der Zeit des Servers und der des Benutzers. Gemäß der Serverzeit werden alle Ressourcen für den 25.08.2020 in Rechnung gestellt.
Nutzungsstatistiken bestehen aus progressiven Werten wie der Anzahl der Anfragen und aus Werten, die Snapshots eines Status in einem bestimmten Zeitraum darstellen. Im Falle des zweiten Datentyps werden die Werte mehrmals täglich neu geladen, aber der Wert vom Ende des Tages (EOD) ist der Wert, der für den bestimmten Tag zugewiesen wird.
| Werttyp | Neu geladen |
|---|---|
| Leerung der Anzahl der Anfragen | Alle 5 Minuten |
| Verwendeter Speicher | 9, 17 und EOD |
| Geräteanzahl | 9, 17 und EOD |
| Abonnierte Anwendungen | 9, 17 und EOD |
| Microservice-Ressourcen | 9, 17 und EOD |
Mandant
Ein Mandant der Cumulocity IoT-Platform kann mehrere Status besitzen:
Microservice
Sämtliche Erweiterungen, die auf der Plattform als Microservice bereitgestellt werden, werden “wie verbraucht” in Rechnung gestellt; dabei entspricht der Rechnungsbeginn dem Verbrauchsbeginn. Nachdem die Anwendung für den Mandanten abonniert wurde, wird ein Anwendungsstart-Prozess ausgelöst, der verschiedene Phasen auf oberster Ebene durchläuft:
Ein Mandant, bei dem Ressourcen in Rechnung gestellt werden, kann den Zeitpunkt anzeigen, zu dem die Abrechnung in den Audit-Logs geändert wurde. Die Audit-Log-Einträge, z. B. " Anwendung ‘…’ wird von X auf Y Instanzen skaliert", enthalten Informationen über Änderungen von Instanzen und Ressourcen, die vom Microservice verbraucht werden.
Mandanten sollten auch in der Lage sein, den vollständigen Lebenszyklus einer Anwendung in den Anwendungsdetails anzuzeigen. Auf der Registerkarte Status werden im Abschnitt Ereignisse sehr niedrigstufige Phasen des Anwendungsstarts angezeigt. Einige der wichtigsten sind:
Pod "apama-ctrl-starter-scope-..." erstellt. - Der Start einer Microservice-Instanz wurde für den Mandanten geplant. Dies bedeutet, dass die Ressourcenzuweisung erfolgreich war, die Anwendung jedoch noch nicht ausgeführt wird (verweist auf den Zustand “Geplant”).Image "apama-ctrl-starter-scope-..." wird gelesen - Der Microservice-Initialisierungsprozess wurde gestartet und das Docker-Image wird bereits heruntergeladen (Zustand “Geplant”).Container erstellt. - Der Microservice-Container wurde erstellt, aber noch nicht gestartet (Zustand “Geplant”).Container gestartet. - Der Microservice-Container wurde gestartet, ist jedoch noch nicht bereit, eingehenden Datenverkehr zu verarbeiten (Zustand “Nicht bereit”).
Audit-Logs und Ereignisse werden entsprechend der Isolationsstufe im Mandantenbereich gespeichert. Bei Microservices mit Isolation mehrerer Mandanten handelt es sich dabei um den Mandanten, der der Eigentümer des Microservice ist, und bei Isolation nach Mandant um den abonnierten Mandanten.
Die Cumulocity IoT-Plattform sammelt zahlreiche unterschiedliche Nutzungsstatistik-Daten, die zur Gebührenabrechnung verwendet werden.
Je nach Vertrag gibt es zwei Abrechnungs-Preismodelle:
Die folgende Tabelle führt auf, welche Werte in welchem Modell zur Gebührenabrechnung verwendet werden:
| Quelle | Name | Mandantennutzungs-Preismodell | Geräte-Preismodell |
|---|---|---|---|
| TenantUsageStatistics | ID | x | x |
| TenantUsageStatistics | Name | x | x |
| TenantUsageStatistics | API-Anfragen | x | |
| TenantUsageStatistics | API-Anfrage von Geräten | x | |
| TenantUsageStatistics | Speicher | x | x |
| TenantUsageStatistics | Höchstwert Speicher | x | |
| TenantUsageStatistics | Hauptgerät | x | |
| TenantUsageStatistics | Höchstwert Hauptgerät | x | |
| TenantUsageStatistics | Geräte | x | x |
| TenantUsageStatistics | Höchstwert Geräte | x | |
| TenantUsageStatistics | Endpunktgeräte | x | |
| TenantUsageStatistics | Abonnierte Anwendungen | x | |
| TenantUsageStatistics | Erstellungszeitpunkt | x | x |
| TenantUsageStatistics | Erzeugte Alarme | x | |
| TenantUsageStatistics | Aktualisierte Alarme | x | |
| TenantUsageStatistics | Erstellte Stammdaten | x | |
| TenantUsageStatistics | Aktualisierte Stammdaten | x | |
| TenantUsageStatistics | Erstellte Ereignisse | x | |
| TenantUsageStatistics | Aktualisierte Ereignisse | x | |
| TenantUsageStatistics | Erstellte Messwerte | x | |
| TenantUsageStatistics | Gesamt Inbound-Transfer | x | |
| TenantUsageStatistics | Übergeordneter Mandant | x | x |
| TenantUsageStatistics | Mandanten-Domain | x | |
| TenantUsageStatistics | Kann Untermandanten erstellen | x | |
| TenantUsageStatistics | Externe Referenz | x | x |
| TenantUsageStatistics | Microservice-CPU-Nutzung gesamt | x | |
| TenantUsageStatistics | Microservice-Speichernutzung gesamt | x | |
| MicroserviceUsageStatistics | CPU-Nutzung pro Microservice | x | |
| MicroserviceUsageStatistics | Speichernutzung pro Microservice | x | |
| DeviceStatistics | Monatliche Messwerte, Ereignisse und Alarme, pro Gerät erstellt und aktualisiert. | x |
Mit der Funktion Data Broker können Daten gezielt mit anderen Mandanten geteilt werden. Sie können folgende Daten teilen:
Navigieren Sie zur Seite Datenkonnektor im Menü Data Broker, wenn Sie anderen Mandanten Daten senden möchten. Navigieren Sie zur Seite Datenabonnements, wenn Sie von anderen Mandanten Daten erhalten möchten.
Beachten Sie folgende Einschränkungen im Zusammenhang mit Data Broker:
Ein Datenkonnektor beschreibt die Daten, die Sie zu einem Zielmandanten senden möchten sowie die URL dieses Mandanten.
Klicken Sie im Navigator auf Datenkonnektor, um eine Liste mit allen aktuell definierten Datenkonnektoren mit ihrem jeweiligen Status anzuzeigen.
Für jeden Datenkonnektor wird die folgenden Information bereitgestellt:
Verwenden Sie den Umschalter, um das Weiterleiten von Daten an den Zielmandanten zu aktivieren bzw. deaktivieren. Werden Daten weitergeleitet, steht der Umschalter auf “Aktiv”. Werden keine Daten weitergeleitet, steht der Umschalter auf “Gesperrt” oder “Ausstehend”. “Gesperrt” bedeutet, dass Sie das Weiterleiten deaktiviert haben. “Ausstehend” bedeutet, dass der Zielmandant das Weiterleiten deaktiviert hat.
Klicken Sie auf Datenkonnektor hinzufügen in der oberen Menüleiste.
Geben Sie in der Registerkarte Einstellungen die folgenden Informationen ein, um einen neuen Datenkonnektor zu erstellen:
| Feld | Beschreibung |
|---|---|
| Titel | Der Name des Datenkonnektors. |
| Ziel-URL für den Datenkonnektor | Die URL des Mandanten, an den Daten weitergeleitet werden sollen. Nach dem Speichern ist dieser Wert nicht mehr editierbar. |
| Beschreibung | Eine Textbeschreibung der Konfiguration. Nach dem Akzeptieren des Abonnements werden sowohl der Name als auch die Beschreibung auf der Zielseite angezeigt. |
| Datenfilter | Eine Reihe von Filtern, die festlegen, was in das Ziel kopiert wird. Sie müssen mindestens einen Filter konfigurieren. |
Klicken Sie auf Filter hinzufügen, um einen neuen Filter zu konfigurieren.
Jeder Datenfilter enthält die folgenden Informationen:
| Feld | Beschreibung |
|---|---|
| Gruppe oder Gerät | Die Gruppe oder das Gerät, die/das weitergeleitet wird. Wird hier eine Gruppe ausgewählt, werden alle Untergruppen und Untergeräte ebenfalls weitergeleitet. Siehe nachstehende Warnung zur Verwendung von "Alle Objekte". |
| API | Der Datentyp, der weitergeleitet wird (Alarme, Ereignisse, Messwerte, Objekte) oder empfangen wird (Operationen). |
| Zu filternde Fragmente | Fragmente, die in einem Gerät vorhanden sein müssen, damit dieses weitergeleitet wird. |
| Zu kopierende Fragmente | Fragmente, die zum Ziel kopiert werden. Wenn hier nichts angegeben wird, werden nur die Standardattribute wie Objekte, Alarme, Ereignisse und Messwerte weitergeleitet (siehe unten). Wählen Sie Alle Fragmente kopieren, um das gesamte Objekt weiterzuleiten. |
| Type-Filter | Weitergeleitete Daten müssen diesen Wert in ihrem "Type"-Attribut haben. |
Klicken Sie auf Speichern, um die Konfiguration zu speichern.
Wenn das Feld Gruppe oder Gerät ausgefüllt ist, wird die gesamte nachfolgende Struktur der Stammdaten an den Zielmandanten weitergeleitet, sobald der Konnektor aktiv ist. Wenn das Feld Gruppe oder Gerät leer ist oder “Alle” enthält, wird die nachfolgende Struktur nicht weitergeleitet. in diesem Fall arbeitet der Filter im “Lazy Mode”, d. h. das Gerät oder Asset wird erst mit dem ersten Ereignis/Messwert/Alarm weitergeleitet.
Wenn der Datentyp Operation in Filtern ausgewählt ist, werden die Operationen, die im Zielmandanten erstellt wurden, an den Ursprungsmandanten weitergeleitet. Dies trifft jedoch nur auf Operationen zu, die die folgenden Bedingungen erfüllen:
Aktualisierungen des Operationsstatus vom Ursprungsmandanten werden an den Zielmandanten weitergeleitet.
Die Kopfzeile eines Datenfilters fasst die Konfiguration in einer Zeile zusammen. Die Attribute, die standardmäßig kopiert werden, sind:
Nach dem Speichern der Konfiguration wird ein Sicherheitscode unter der Konfiguration angezeigt. Dieser Sicherheitscode verhindert unbeabsichtigtes Weiterleiten von Daten. Sie müssen diesen Sicherheitscode getrennt einem Benutzer mit Administrationsrechten für den Zielmandanten mitteilen. Durch Klicken auf das Kopieren-Symbol neben dem Sicherheitscode können Sie diesen in Ihre Zwischenablage kopieren.
Klicken Sie auf den Konnektortitel oder klicken Sie auf das Menüsymbol rechts neben einem Datenkonnektor-Eintrag und anschließend auf Bearbeiten.
Bearbeiten Sie in der Registerkarte Einstellungen die Datenkonnektor-Konfiguration.
Weitere Informationen zu den Einstellungen finden Sie unter So fügen Sie einen Datenkonnektor hinzu.
Klicken Sie auf das Menüsymbol rechts neben einem Datenkonnektor-Eintrag und anschließend auf Duplizieren, um einen weiteren Datenkonnektor mit der gleichen Konfiguration zu erstellen.
Klicken Sie auf das Menüsymbol rechts neben einem Datenkonnektor-Eintrag und anschließend auf Löschen, um die Datenweiterleitung zu stoppen und den Datenkonnektor zu löschen.
Öffnen Sie einen Datenkonnektor und wechseln Sie zur Registerkarte Alarme, um aktuelle Alarme für den Datenkonnektor anzuzeigen.
Weitere Informationen zu Data Broker-Alarmen finden Sie unter Troubleshooting weiter unten.
Weitere Informationen zu Alarmen im Allgemeinen finden Sie unter Device Management > Überwachen und Steuern von Geräten > Verwenden von Alarmen.
Auf der Seite Datenabonnements können Sie bestehende Datenabonnements verwalten und neue anlegen.
Klicken Sie auf Datenabonnements, um eine Liste mit allen aktuell zu Ihrem Mandanten weitergeleiteten Daten anzuzeigen.
Für jedes Abonnement wird der Name, der Zielmandant und der Status (aktiviert oder deaktiviert) auf einer Karte bereitgestellt.
Verwenden Sie den Umschalter, um zeitweilig das Weiterleiten von Daten in Ihren Mandanten zu beenden.
Navigieren Sie nun zur Device Management- oder Cockpit-Anwendung. Dort finden Sie eine neue “virtuelle Gruppe” mit einem speziellen Symbol (siehe Abbildung unten), die die weitergeleiteten Geräte anzeigt. Diese Gruppe hat denselben Namen wie das Abonnement. Geräte werden auf der Empfängerseite verzögert erstellt, sobald sie, nach Einrichten eines aktiven Abonnements, das erste mal Daten senden.
Klicken Sie auf das Menüsymbol und anschließend auf Löschen, um die Datenweiterleitung zu stoppen und den Datenkonnektor zu löschen.
Wenn der Data Broker die Verbindung zu einem Zielmandanten nicht herstellen kann, wird ein KRITISCHER Alarm ausgelöst und dabei der betroffene Konnektor angezeigt.
Im Ursprungsmandanten reiht Data Broker die Daten, die nicht sofort an den Zielmandanten weitergeleitet werden können, in eine Wartschlange ein. Die Datenmenge, die in die Warteschlange eingereiht werden kann, ist begrenzt. Kann Cumulocity IoT keine weiteren Daten in die Warteschlange einreihen, werden die ältesten Daten aus der Warteschlange entfernt. In diesem Fall wird im Mandanten ein WICHTIGER Alarm ausgelöst und dabei der betroffene Konnektor angezeigt.
Ebenso wird bei einem Überlauf der Eingangswarteschlange ein Alarm ausgelöst.
Um die Anzahl der Alarme zu reduzieren, werden Alarme höchstens einmal pro Minute ausgelöst.
Der Microservice-basierte Data Broker nutzt den Cumulocity IoT Messaging Service, der eine zuverlässige, skalierbare und hochleistungsfähige Bewegung von IoT-Daten ermöglicht. Der Microservice-basierte Data Broker ähnelt in seiner Funktionalität dem bisherigen Data Broker, außer dass zu seiner Nutzung ein Microservice, der databroker-agent-server, aktiviert werden muss.
Der Cumulocity IoT Messaging Service ist eine optionale Komponente der Cumulocity IoT-Plattform, die eventuell aktiviert werden muss, bevor der Microservice-basierte Data Broker verwendet werden kann. Der ursprüngliche Data Broker wird vorerst neben dem Microservice-basierten Data Broker weiter betriebsfähig bleiben, und die Benutzer können für jeden Mandanten individuell auswählen, welcher Data Broker verwendet werden soll.
Für die gemeinsam genutzten Public-Cloud-Instanzen der Cumulocity IoT-Plattform ist der Messaging Service ab Version 10.13 standardmäßig aktiviert, und der Microservice-basierte Data Broker kann auf Wunsch für einzelne Mandanten aktiviert werden, die bereits Zugriff auf den ursprünglichen Data Broker haben. Für dedizierte und selbst gehostete Instanzen sind der Messaging Service und der Microservice-basierte Data Broker für Version 10.10 und höher verfügbar, müssen aber explizit aktiviert werden.
Bitte wenden Sie sich an den Produkt-Support, um Näheres über die Verwendung von Messaging Service und Microservice-basiertem Data Broker in Ihrer Cumulocity IoT-Umgebung zu erfahren. Im Messaging Service - Installation & Operations Guide finden Sie technische Details zur erforderlichen Konfiguration. Beachten Sie jedoch, dass diese Aufgaben nur von einem Cumulocity IoT-Plattform-Administrator und nicht von einem normalen Benutzer ausgeführt werden können.
Zusammenfassung: Um mit dem Microservice-basierten Data Broker arbeiten zu können, müssen die folgenden Anforderungen erfüllt sein:
feature-broker), sofern diese noch nicht abonniert ist.databroker-agent-server).
Nähere Informationen zur Handhabung von Datenkonnektoren finden Sie unter Datenkonnektoren.
Nähere Informationen zur Handhabung von Datenabonnements finden Sie unter Datenabonnements.
Nach dem Aktivieren des Microservice-basierten Data Brokers sollten Ihre vorhandenen Datenkonnektoren ohne weitere Konfiguration weiterhin funktionieren.
Der Management Tenant kann nicht als Data-Broker-Ursprungsmandant verwendet werden und dieser Alarm wird beim Versuch ausgelöst, den Data Broker-Agenten für einen Management Tenant zu abonnieren.
Der Data Broker-Agent ist vorkonfiguriert für die Überwachung aller Konnektoren bezüglich der Anzahl der gesendeten Weiterleitungsanfragen. Wenn diese Anzahl einen vorkonfigurierten Schwellenwert erreicht, wird beim Mandanten ein KRITISCHER Alarm ausgelöst. Geschieht dies, werden die Daten gespeichert, bis die Verbindung wiederhergestellt ist und die Daten wieder weitergeleitet werden können. Zu fehlgeschlagenen Anfragen kann es kommen, wenn der den Data Broker abonnierende Mandant nicht mehr erreichbar ist.
Der Data Broker-Agent ist so vorkonfiguriert, dass er die Rate überwacht, mit der Ereignisse an ihr Ziel geliefert werden. Wenn Ereignisse nicht schnell genug geliefert werden können, werden Alarme wegen langsamer Verarbeitung ausgelöst. Ein Alarm wegen langsamer Verarbeitung enthält eine Konnektor-ID, an der Sie erkennen können, welcher Mandant betroffen ist.
Dieser Alarm wird ausgelöst, wenn die Latenz für die Nachrichtenübermittlung einen festgelegten Schwellenwert überschreitet. Dies erfolgt in der Regel dann, wenn es aufgrund verschiedener Faktoren zu einem Rückstand an unzugestellten Ereignissen an den Zielmandanten gekommen ist.
Der Data Broker überwacht die Datenrate, mit der Ereignisse weitergeleitet werden. Liegt diese Rate unterhalb eines vorkonfigurierten Schwellenwerts, wird ein Alarm wegen langsamer Verarbeitung ausgelöst. Hierzu kann es aufgrund eines langsamen Netzwerks kommen.
Die Speicherbegrenzung gilt für einen Mandanten, wenn der Plattformadministrator ein Speicherkontingent pro Gerät eingerichtet hat. Der insgesamt verfügbare Speicher für einen Benutzer wird mittels der Formel Speicherkontingent pro Gerät x Anzahl der Geräte berechnet. Jede Nacht wird überprüft, ob das Kontingent überschritten wurde.
Ist das Kontingent überschritten, wird eine E-Mail an alle Mandantenadministratoren gesendet mit der Information, dass in der folgenden Nacht Daten gelöscht werden. Ist das Kontingent nach 24 Stunden weiterhin überschritten, werden alle Datenhaltungsbegrenzungen um einen festen Prozentwert herabgesetzt. Daraus resultiert, dass das Kontingent pro Gerät entsprechend verringert wird.
Nehmen wir an, ein Mandant hat ein Speicherkontingent von 10 GB. Datenhaltungsregeln gelten 80 Tage für Messwerte und 90 Tage für alle anderen Daten.
Tag 1 - Die nächtliche Überprüfung ergibt eine Gesamtspeichernutzung von 13 GB. Eine E-Mail wird an alle Mandantenadministratoren gesendet.
Tag 2 - Die Gesamtspeichernutzung beträgt weiterhin 13 GB. Das System ermittelt, dass eine Reduzierung der Datenhaltung um 15% ausreichend ist, um unterhalb des Speicherkontingents zu bleiben. Daher werden alle Messwerte, die älter sind als 68 Tage (80 Tage - 15%) sowie alle anderen Daten, die älter sind als 77 Tage (90 Tage - 15%) gelöscht.
Die Gesamtspeichernutzung beträgt nun 9,8 GB.
Die Funktion ist nur sichtbar, wenn ein Speicherkontingent für den Mandanten gesetzt wurde.
Mandantenadministratoren können eine Benutzergruppe (globale Rolle) festlegen, an die täglich eine E-Mail versendet wird, wenn der genutzte Speicher einen ebenfalls zu konfigurierenden Prozentsatz des Speicherkontingents überschreitet. Standardmäßig wird eine E-Mail an die Rolle “Admin” versendet, wenn die Speichernutzung 80% des Gesamtkontingents erreicht.
Die Warn-E-Mail kann auch deaktiviert werden.
Der Cumulocity IoT Betriebsspeicher bietet erweiterten Support für Zeitreihen (sogenannte Zeitreihensammlungen) für Messdaten. Im Folgenden wird beschrieben, wie sich diese Funktion aktivieren/deaktivieren lässt.
Der erweiterte Support für Zeitreihen kann über eine REST API als Mandantenkonfiguration konfiguriert werden. Das folgende Beispiel zeigt, wie Sie Zeitreihensammlungen für einen Untermandanten aktivieren können:
POST {sub-tenant-url}/tenant/options
Content-Type: application/json
{
"category": "configuration",
"key": "timeseries.mongodb.collections.mode",
"value": "ENABLED"
}
Das folgende Beispiel zeigt, wie Sie Zeitreihensammlungen für einen Untermandanten deaktivieren können:
POST {sub-tenant-url}/tenant/options
Content-Type: application/json
{
"category": "configuration",
"key": "timeseries.mongodb.collections.mode",
"value": "DISABLED"
}
Die Konfiguration wirkt sich auf die Sammlung aus, in der die Messdaten gespeichert sind. Durch Aktivieren oder Deaktivieren des Attributs werden Sammlungen im Hintergrund gewechselt. Dies kann unter Umständen dazu führen, dass die Daten in mehreren Sammlungen gespeichert werden. Um dies zu verhindern, konfigurieren Sie das Attribut nur zu Beginn einer Mandanten-Einstellung, idealerweise, wenn noch keine Messdaten gespeichert sind. Migration und nahtlose Konfiguration werden Bestandteile zukünftiger Versionen sein.
DEAKTIVIERT zu setzen, da dies zu Datenverlusten führen kann. Tun Sie dies nur bei einem Problem oder Notfall.Die folgenden APIs werden nicht unterstützt und es gibt keinen Ersatz für sie:
GET /measurement/measurements/{id}DEL /measurements/measurement/{id}Die folgende API wird teilweise unterstützt:
DEL /measurements/measurement/In Version 10.16 werden die Parameter dateFrom und dateTo nicht unterstützt. Verwenden Sie stattdessen Datenhaltungsregeln, um abgelaufene Messdaten aus dem Betriebsspeicher zu entfernen.
In 10.17+ müssen die Parameter dateFrom und dateTo auf volle Stunden gekürzt werden (z. B. 2022-08-19T14:00:00.000Z), andernfalls wird ein Fehler gemeldet.
Mit der folgenden Anfrage können Sie den Wert des Attributs für Zeitreihensammlungen überprüfen:
GET /tenant/options/configuration/timeseries.mongodb.collections.mode
Content-Type: application/json
Beispiel für eine Antwort, wenn die Konfiguration aktiviert ist:
{
"category": "configuration",
"key": "timeseries.mongodb.collections.mode",
"value": "ENABLED"
}
Wenn die Konfiguration für den Mandanten überhaupt nicht festgelegt ist, wird bei der oben genannten Anfrage der Antwortcode 404 erzeugt.