Workplace Management: Allgemeine Webdienste
Lango: Language and translation manager
Allgemein
Webservices können Daten in einer Workplace Management-Umgebung abrufen, erstellen und aktualisieren.
Die Workplace Management API verwendet ein REST-basiertes Framework. Die Autorisierung basiert auf Bearer-Tokens und einem Preshared Key.
Webdienste sind sofort verfügbar und in den folgenden Teilen für einige der am häufigsten genutzten Objekte dokumentiert. Diese Objekte sind:
Masterdata:
Organisationen
Kontaktpersonen
Gebäude
Bereiche
Vermögenswerte
Problemtypen
Vorgänge:
Anfragen
Arbeitsaufträge zur Korrektur
Vorbeugende Arbeitsaufträge
Derzeit verwenden diese APIs allgemeine Endpunkte. Künftig könnten bereichsspezifische Endpunkte geschaffen werden, wie dies für den Bereich der Reservierungen der Fall ist.
Vorbedingungen
Um die APIs nutzen zu können, gelten einige Vorbedingungen. Ein (technischer) Berater kann bei diesen Voraussetzungen helfen.
Eine Workplace Management-Umgebung mit den folgenden Unterbedingungen:
Eingehende Webdienste werden über die folgenden Zugriffsregeln (Registerkarte "Authentifizierung" in den allgemeinen Einstellungen) aktiviert (dies erfolgt über den Kundensupport):
Ein externes App-Objekt (das auch über die Registerkarte Authentifizierung in den allgemeinen Einstellungen als Stufe-3-Admin erstellt werden kann) mit einer Vertrauensbeziehung (Schlüsseltyp = AES Shared Key) ist verfügbar, wobei der autorisierte Systembenutzer der Vertrauensbeziehung auch mit der externen App in der Registerkarte Systembenutzer verknüpft ist:
Stellen Sie sicher, dass Sie die Domäne in das Feld "Erlaubte Ursprünge für REST-Webdienste" (Client-Einstellungen, Authentifizierung) eintragen, wenn Sie externen Domänen den asynchronen Zugriff auf die generischen Webdienste erlauben wollen (Cross-origin resource sharing (CORS)Cross-origin resource sharing (CORS))
Erforderliche Parameter
Die folgenden Parameter werden benötigt, um die API-Aufrufe erfolgreich einzurichten:
Parameter | Beschreibung | Beispiel |
|---|
Parameter | Beschreibung | Beispiel |
|---|---|---|
Server | die Basis-URL des Mieters, entweder die mieterspezifische Domäne oder ein allgemeiner Server | |
authentication-mode | Fester Wert: "GENERIC". "Relevant für die OAuth 2.0-basierte Inhaber-Token-Authentifizierung. Dies ist NUR für das automatisierte Scripting für Token-Anfragen in Postman erforderlich. | GENERISCH |
clientRef | Der Hinweis auf die Umwelt | Demotenant |
Nutzername | Der Benutzername des Systembenutzers, in dessen Namen Sie sich authentifizieren möchten. Relevant für die Inhaber-Token-Authentifizierung. (Dieser Benutzer muss über die Registerkarte Systembenutzer mit der externen Anwendung verknüpft sein) | demo_api |
app-id | Die Referenz der externen Anwendung. Relevant für die Authentifizierung mit dem Inhaber-Token | DTW-EA-001 |
x-access-id-value | Die Zugriffskennung der Vertrauensbeziehung. Relevant für die Authentifizierung mit dem Inhaber-Token | demo_api_id |
Geheimschlüssel | Der Schlüssel der Vertrauensbeziehung. Relevant für die Authentifizierung mit dem Inhaber-Token | DB2E51543E463290B946602B8047CC9E16048E2C99728DB2E51543E463290B946602B8047CC9E16048E2C99728 |
API-Autorisierungsschema OAuth 2.0
Allgemein
Um Zugriff auf die von der Workplace Management REST API zur Verfügung gestellten Ressourcen zu erhalten, müssen Clients zunächst ein Inhaber-Token anfragen. Das Verfahren hierfür wird im Folgenden beschrieben:
Art des Zuschusses
Bearer-Tokens können mit dem OAuth-Grant-Typ "Resource Owner Password Credentials" bezogen werden. Obwohl dieser Grant-Typ nahelegt, dass ein Passwort verwendet wird, ist dies in diesem Autorisierungsschema nicht der Fall. Anstelle eines Kennworts sollte eine Token-Anfrage-Nachricht mit einem vorab freigegebenen AES-Schlüssel verschlüsselt werden, der vom Endpunkt validiert wird, und bei erfolgreicher Authentifizierung wird ein Inhaber-Token zurückgegeben. Die von den Ressourcen-Endpunkten zurückgegebenen Ressourcendaten hängen von den Zugriffsrechten des Benutzers auf die betreffenden Ressourcen ab.
Token-Anfrage-Nachricht
Bei der Token-Anfrage handelt es sich um eine JSON-Nachricht, die die folgenden Daten enthalten sollte, wobei Begriffe in Klammern durch ihre literalen Werte ersetzt werden sollten:
{
"grant_type": "password,""
"username": "[username of the resource owner]",
"password": "",
"scope": "session v1 v2 v3",
"app_id": "[external app id]"
}Es ist möglich, den wörtlichen Alias "axx::access::admin" als Benutzernamen zu verwenden (ohne die zusätzlichen Anführungszeichen). In diesem Fall wird anstelle des tatsächlichen Benutzernamens des Benutzers, der die Ressourcen anfragt, der Zugriff im Namen des standardmäßig autorisierten Systembenutzers angefragt, der mit der von der externen Anwendung verwendeten (auf dem AES Preshared Key basierenden) Vertrauensbeziehung verbunden ist.
Verschlüsselung der Token-Anfrage-Nachricht
Die Nachricht über die Token-Anfrage sollte nun mit dem gemeinsamen AES-Schlüssel verschlüsselt werden, der im Workplace Management im AES-CBC-Modus generiert werden kann, was zu einem Chiffretext und einem IV (Initialisierungsvektor) führt. Erstellen Sie nun eine Zeichenkette nach dem folgenden Format:
[length of the base64 encoded ciphertext]:[base64 encoded ciphertext][base64 encoded IV]Die sich daraus ergebende Zeichenfolge sollte in der eigentlichen Token-Anfrage als "encrypted-params" gesendet werden; siehe nächster Abschnitt.
Erstellen Sie eine aktuelle HTTP-Anfrage für den Token-Endpunkt
Um nun die HTTP-Anfrage für den Token-Endpunkt zu bilden, muss eine POST Anfragen sollten an den folgenden Endpunkt gerichtet werden (wobei der Server durch die Server-Domäne ersetzt werden sollte):
https://[server]/axxerion/aaa/registration/oauth2/tokenDie Anfrage sollte mindestens die folgenden Kopfzeilen enthalten (wobei die Begriffe in Klammern wiederum durch die tatsächlichen Werte ersetzt werden sollten):
Der Körper der Anfrage sollte URL-kodierte Formulardaten enthalten, wie in der folgenden Tabelle beschrieben:
Schlüssel | Wert |
|---|
Schlüssel | Wert |
|---|---|
| [Verschlüsselte Parameter] |
Wenn der Server die Anfrage zur Autorisierung genehmigt, 200 OK sollten Antworten mit dem Überbringer-Token empfangen werden, der für den Zugriff auf die Ressourcenendpunkte verwendet werden kann, solange das Token gültig ist.
Ein Beispiel für das Skript finden Sie in den Beispiel-Postman-Sammlungen auf der Registerkarte Skript für Voranfragen, die am Ende dieses Dokuments heruntergeladen werden kann.
Überblick über APIs
Jeder Endpunkt besteht aus einer Basis-URL: https://{server}/webservices/{clientRef}}/rest
Sowohl "server" als auch "clientRef" sind auf der Grundlage der Umgebungsparameter auszufüllen.
Anhand der Art des Endpunkts wird der zweite Teil der Endpunkt-URL bestimmt:
Derzeit sind zwei Arten von Endpunkten verfügbar:
Abrufen von Daten aus dem Workplace Management. Hierfür wird die generische Funktion "completereportresult" verwendet. Dies ist derselbe Endpunkt für jeden Aufruf; die spezifische Datenanfrage (Bericht) wird dem Hauptteil des Aufrufs über einen Referenzwert hinzugefügt (obligatorischer und fester Wert pro Aufruf).
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Beispiel Endpunkt: https://demotenant.axxerion.com/webservices/demotenant/rest/functions/completereportresult
Erstellen eines Objekts (Asset oder Anfrage). Dazu wird die generische Funktion "createupdate" verwendet. Das eigentliche Objekt und die Kategorie des Objekts (z. B. Asset in der Kategorie "Möbel" erstellen), das erstellt werden soll, wird dem Endpunkt nach dem createupdate-Teil ebenfalls hinzugefügt.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions//createupdate{ObjectName}/{ObjectCategoryId}
Beispiel Endpunkt: https://demotenant.axxerion.com/webservices/demotenant/rest/functions/Asset/710000000172835
Der Objektname kann entweder "Asset" oder "Anfrage" sein, die ObjectCategoryId ist nur für Assets relevant (fester Wert für Anfragen). Die Optionen für Assets können über eine der nachstehenden APIs abgerufen werden.
Die folgenden APIs sind derzeit standardmäßig verfügbar:
Erhalten Sie eine Liste von Organisationen
Dieser POST-Aufruf holt alle Organisationen (eigene Organisationen und Lieferanten) im Mandanten mit den relevanten Informationen pro Organisation.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Organisationen_01", "filterFields":["E-Mail"], "filterValues":["example@email.com"]}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Report_Organisationen_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Organisationen auf der Grundlage einer E-Mail-Adresse zu filtern: E-Mail
Beispielhaftes Ergebnis:
Eine Liste von Personen erhalten
Dieser POST-Aufruf holt alle Personen des Mieters mit den entsprechenden Informationen pro Person.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Kontakte_01", "filterFields":["E-Mail"], "filterValues":["noreply@spacewell.com"]}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Report_Kontakte_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Personen auf der Grundlage einer E-Mail-Adresse zu filtern: E-Mail
Beispielhaftes Ergebnis:
Eine Liste der Gebäude erhalten
Mit diesem POST-Aufruf werden alle Gebäude des Mieters mit den entsprechenden Informationen pro Gebäude abgerufen.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Properties_01"}
Die Referenz ist obligatorisch; sie bestimmt den korrekten Bericht, der ausgeführt werden soll: API_Report_Properties_01
Dieser Aufruf unterstützt keine zusätzlichen Filterfelder
Beispielhaftes Ergebnis:
Liste der Gebiete erhalten
Mit diesem POST-Aufruf werden alle Bereiche des Mieters mit den entsprechenden Informationen pro Bereich abgerufen.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Areas_01", "filterFields":["Eigenschaft"], "filterValues":[[1210000000000849]]}
Die Referenz ist obligatorisch; sie bestimmt den korrekten Bericht, der ausgeführt werden soll: API_Bericht_Bereiche_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Bereiche nach einem bestimmten Gebäude zu filtern: Eigentum
Der Filterwert muss die Id des Gebäudes sein, wie sie über den API-Aufruf für Gebäude abgerufen wird.
Beispielhaftes Ergebnis:
Eine Liste der Vermögenswerte erhalten
Mit diesem POST-Aufruf werden alle Anlagen des Mieters mit den entsprechenden Informationen pro Anlage abgerufen.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Asset_01", "filterFields":["Property", "Area"], "filterValues":[[1000066632],[1000212917]]}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Report_Asset_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Assets nach einem bestimmten Gebäude zu filtern: Eigenschaft
Es ist möglich, die Assets nach einem bestimmten Bereich zu filtern: Bereich
Der Filterwert muss die Id des Gebäudes und/oder Bereichs sein, wie sie über Gebäude- und Bereichs-API-Aufrufe abgerufen wird.
Beispielhaftes Ergebnis:
Eine Liste der Asset-Kategorien abrufen
Dieser POST-Aufruf ruft alle Asset-Kategorien im Mieter ab. Die Id einer Asset-Kategorie kann verwendet werden, um ein neues Asset in der gewünschten Kategorie zu erstellen (siehe Ein Asset erstellen). Z.B. Auto, Fahrrad, Kaffeemaschine.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Asset_Categories_01"}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Bericht_Vermögenskategorien_01
Dieser Aufruf unterstützt keine zusätzlichen Filterfelder
Beispielhaftes Ergebnis:
Abrufen einer Liste von Anfragen.
Mit diesem POST-Aufruf werden alle Anfragen des Mandanten mit den entsprechenden Informationen pro Anfrage abgerufen.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Requests_01", "filterFields":["CreatedSince", "CreatedUntil"], "filterValues":["2023-01-01T00:00:00Z","2023-08-01T00:00:00Z"]}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Report_Requests_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Anfragen nach den Erstellungszeiten zu filtern: ErstelltSeit und ErstelltBis
Datums-/Zeitfilter müssen in der kombinierten Datums- und Zeitdarstellung nach ISO 8610 eingegeben werden (siehe https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations)
Die folgenden Filterfelder können ebenfalls verwendet werden (nicht im obigen Textkörper dargestellt):
Asset (Geben Sie den ID-Wert eines Assets an, um die mit diesem Asset verbundenen Anfragen zu erhalten)
Bereich (Geben Sie den ID-Wert eines Bereichs an, um die mit diesem Bereich verbundenen Anfragen zu erhalten)
Eigenschaft (Geben Sie den ID-Wert einer Eigenschaft an, um die mit dieser Eigenschaft verbundenen Anfragen zu erhalten)
Beispielhaftes Ergebnis:
Eine Liste von Problemtypen erhalten
Mit diesem POST-Aufruf werden alle Problemtypen (ein Problemtyp wird verwendet, um die Art der Anfrage und die Servicegruppe zu bestimmen, die für die Bearbeitung der Anfrage zuständig ist) im Mandanten mit den entsprechenden Informationen pro Problemtyp abgerufen.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_ProblemTypes_01"}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Bericht_Problemtypen_01
Dieser Aufruf unterstützt keine zusätzlichen Filterfelder
Beispielhaftes Ergebnis:
Eine Liste der Mitglieder pro Dienstgruppe erhalten
Dieser POST-Aufruf holt alle Kontakte in einer Servicegruppe (eine Servicegruppe wird in einem Problemtyp verwendet und dient dazu, zu bestimmen, welche Gruppe für die Bearbeitung der Anfrage zugewiesen wird) im Mandanten mit den relevanten Informationen pro Servicegruppe.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_ServiceGroupMembers_01"}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Report_ServiceGroupMembers_01
Dieser Aufruf unterstützt keine zusätzlichen Filterfelder
Beispielhaftes Ergebnis:
Erhalten Sie eine Liste von Korrekturaufträgen
Dieser POST-Aufruf holt alle Korrekturarbeitsaufträge (Arbeitsaufträge, die auf eine Anfrage hin erstellt wurden) im Mieter mit den entsprechenden Informationen pro Arbeitsauftrag.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Korrekturanweisungen_01", "filterFields":["CreatedSince", "CreatedUntil"], "filterValues":["2023-01-01T00:00:00Z","2023-09-01T00:00:00Z"]}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Bericht_Korrektur_Arbeitsauftraege_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Arbeitsaufträge nach den Erstellungszeiten zu filtern: ErstelltSeit und ErstelltBis
Datums-/Zeitfilter müssen in der kombinierten Datums- und Zeitdarstellung nach ISO 8610 eingegeben werden (siehe https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations)
Die folgenden Filterfelder können ebenfalls verwendet werden (nicht im obigen Textkörper dargestellt):
Asset (Geben Sie den ID-Wert eines Assets an, um die mit diesem Asset verknüpften Korrekturarbeitsaufträge zu erhalten)
Bereich (Geben Sie den ID-Wert eines Bereichs an, um die mit diesem Bereich verbundenen Arbeitsaufträge zu erhalten)
Eigenschaft (Geben Sie den ID-Wert einer Eigenschaft an, um die mit dieser Eigenschaft verknüpften Korrekturarbeitsaufträge zu erhalten)
Anfrage (spezifisch der ID-Wert einer Anfrage, um die Korrekturarbeitsaufträge für diese Anfrage zu erhalten)
Beispielhaftes Ergebnis:
Eine Liste mit präventiven Arbeitsaufträgen erhalten
Dieser POST-Aufruf holt alle präventiven Arbeitsaufträge (Arbeitsaufträge, die über einen Wartungsplan erstellt wurden) im Mieter mit den entsprechenden Informationen pro Arbeitsauftrag.
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/completereportresult
Körper:
{ "Referenz": "API_Report_Präventive_Arbeitsaufträge_01", "filterFields":["CreatedSince", "CreatedUntil"], "filterValues":["2023-01-01T00:00:00Z","2024-01-01T00:00:00Z"]}
Die Referenz ist obligatorisch; sie bestimmt den richtigen Bericht, der ausgeführt werden soll: API_Bericht_Korrektur_Arbeitsauftraege_01
Die Filterfelder sind optional.
Verfügbare Filterfelder:
Es ist möglich, die Arbeitsaufträge nach den Erstellungszeiten zu filtern: ErstelltSeit und ErstelltBis
Datums-/Zeitfilter müssen in der kombinierten Datums- und Zeitdarstellung nach ISO 8610 eingegeben werden (siehe https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations)
Die folgenden Filterfelder können ebenfalls verwendet werden (nicht im obigen Textkörper dargestellt):
(Da präventive Arbeitsaufträge mit mehreren Objekten verknüpft sein können (z. B. Wartung für 10 Aufzüge), funktioniert die Filterung bei korrigierenden Arbeitsaufträgen etwas anders. Ein vorbeugender Arbeitsauftrag kann mehr als einmal zurückgegeben werden, abhängig von der Anzahl der Objekte, mit denen er verknüpft ist. Um nach einem bestimmten Objekt zu filtern, kann die ID des Objekts hinzugefügt werden. Dabei kann es sich um eine Anlage, einen Bereich oder ein Gebäude handeln. (Beachten Sie, dass ein Arbeitsauftrag, der mit einer bestimmten Anlage verknüpft ist, keine Ergebnisse liefert, wenn er nach dem Gebäude dieser Anlage gefiltert wird; er muss speziell nach dieser Anlage gefiltert werden (oder ohne Filter).
Objekt (Geben Sie den ID-Wert einer Anlage, eines Bereichs oder eines Gebäudes an, um die mit diesem Objekt verbundenen präventiven Arbeitsaufträge zu erhalten)
Beispielhaftes Ergebnis:
Eine Anlage erstellen
Dieser Post-Aufruf wird verwendet, um ein neues Asset zu erstellen
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/createupdate/Asset/{assetCategory}}
Der Wert "{{assetCategory}" in der Endpunkt-URL sollte auf einen Asset-Kategorie-Id-Wert gesetzt werden (abgerufen über die eine Liste der Asset-Kategorien erhalten Aufruf)
Körper mit Beispielwerten:
{ "Name": "Beispiel Laptop 2", "externalReference": "987654321", "serialNumber": "123456789", "Handelsname": "DTwin turbo", "Modellname": "Modell X1", "Menge": "1", "HerstellerKontaktId": "1210000000005286", "supplierContactId": "", "purchaseDate": "2023-01-01T00:00:00Z", "propertyId": "1210000000000849", "areaId": "1210000000048836", "parentAssetId": "1210000000008548"}
Die folgenden Felder können über den Body eingestellt werden (alle optional):
Parameter | Beschreibung |
|---|
Parameter | Beschreibung |
|---|---|
Name | Freier Text (max. 255 Zeichen) |
ExterneReferenz | Freier Text (max. 255 Zeichen) |
serialNumber | Freier Text (max. 255 Zeichen) |
modelName | Freier Text (max. 255 Zeichen) |
Menge | Integer |
manufacturerContactId | Id-Wert einer Organisation oder Person (wird über den erhalten eine Liste von Organisationen oder eine Liste von Personen erhalten API Aufrufe) |
supplierContactId | Id-Wert einer Organisation oder Person (wird über den erhalten eine Liste von Organisationen oder eine Liste von Personen erhalten API Aufrufe) |
KaufDatum | Datums-/Zeitfilter müssen in der kombinierten Datums- und Zeitdarstellung nach ISO 8610 eingegeben werden (siehe https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations) |
propertyId | Id-Wert eines Gebäudes (wird über die Funktion eine Liste von Gebäuden erhalten API-Aufruf) |
areaId | Id-Wert eines Bereichs ( Abgerufen über die erhalten eine Liste von eine Bereiche API-Aufruf) |
parentAssetId | Id-Wert eines Vermögenswerts ( Abgefragt über die erhalten eine Liste von eine Vermögenswerte API-Aufruf) |
Die Antwort ist der Id-Wert des neu erstellten Assets:
Eine Anfrage erstellen
Dieser Post-Aufruf dient dazu, eine neue Anfrage zu erstellen
Endpunkt: https://{server}/webservices/{clientRef}}/rest/functions/createupdate/Anfrage/1000000786
Körper mit Beispielwerten:
{ "fromContactId": "1210000000004567", "Name": "Testanfrage", "Beschreibung": "Testanfrage", "problemTypeId": "1210000000005757", "propertyId": "12100000000057634", "areaId": "1210000000005764", "assetId": "1210000000005734"}
Die folgenden Felder können über den Body eingestellt werden (alle optional):
Parameter | Beschreibung |
|---|
Parameter | Beschreibung |
|---|---|
fromContactId | Id-Wert einer Organisation oder Person (wird über den erhalten eine Liste von Organisationen oder eine Liste von Personen erhalten API |
Name | Freier Text (max. 255 Zeichen) |
Beschreibung | Freier Text (max. 255 Zeichen) |
problemTypeId | Id-Wert eines Problemtyps (Abgerufen über die erhalten eine Liste von Problemtypen API-Aufruf) |
propertyId | Id-Wert eines Gebäudes (wird über die Funktion erhalten eine Liste von Gebäude API-Aufruf) |
areaId | Id-Wert eines Bereichs ( Abgerufen über die erhalten eine Liste von Bereiche API-Aufruf) |
assetId | Id-Wert eines Vermögenswerts (abgerufen über die erhalten eine Liste von Vermögenswerte API-Aufruf) |
Die Antwort ist der Id-Wert der neu erstellten Anfrage
Aktualisieren eines bestehenden Objekts
Durch einen PUT-Aufruf ist es möglich, eines der oben genannten Objekte zu aktualisieren.
Dazu ist der folgende Endpunkt erforderlich:https://{server}/webservices/{clientRef}}/rest/functions/update/{ObjectType}/{ID}
Der {ObjecType} sollte der Name des Objekttyps sein. Z. B. "Asset" oder "Anfrage".
Die {ID} sollte der ID-Wert des Objekts sein, das Sie aktualisieren möchten
Der Hauptteil des Aufrufs sollte die zu aktualisierenden Felder enthalten. Siehe Beispiele oben bei den Aufrufen zum Erstellen.
Projekt Postbote
Die folgenden Links enthalten ein Beispiel Postbote Projekt und eine (Dummy-)Umgebung auf der Grundlage der oben beschriebenen API-Aufrufe. Die Umgebung sollte auf der Grundlage der tatsächlich zu verwendenden Umgebungsparameter ausgefüllt werden.
