Objektmodell für die Handelspartnerverwaltung: REST-Endpunkt

Letzte Aktualisierung: August 2015

Für die TPM OM-APIs verwendeter REST-Endpunkt.

Nachdem Sie Ihren BizTalk Service bereitgestellt haben (siehe die Schritte unter http://go.microsoft.com/fwlink/p/?LinkId=299821), wird eine Bereitstellungs-URL für Ihre Umgebung erstellt. Sie können diese URL verwenden, um zum REST-Endpunkt zu gelangen, der für die TPM-OM-APIs verwendet wird.

In diesem Thema:

Entdecken der TPM-OM-Entitäten

TPM OM-API: Informationen zu Art und Ort der Ausführung

Herstellen einer Verbindung mit dem TPM-OM-API-REST-Endpunkt

Erstellen von .NET-Anwendungen mithilfe der TPM-OM-API

TPM-OM-API verwendet die $metadata-Operation, um die Entitäten sichtbar zu machen. Der URI zum Abrufen der Metadaten ist:

<base_URL>/default/$PartnerManagement/$metadata

Hier verweist <Basis_URL> auf die Bereitstellungs-URL der BizTalk Services-Umgebung. Wenn die Bereitstellungs-URL beispielsweise https://mybiztalkservice.biztalk.windows.net ist, sollte die URL zum Abrufen der Metadaten https://mybiztalkservice.biztalk.windows.net/default/$PartnerManagement/$metadata sein.

Diese URL ermöglicht Ihnen das Abrufen aller gültigen Entitätstypen, Entitätseigenschaften, Zuordnungen usw. Sie können die Metadaten darüber hinaus anzeigen, indem Sie den Endpunkt in einem Browser aufrufen.

Mithilfe der TPM OM-API können Benutzer Anwendungen schreiben, um die Entitäten zu erstellen und zu verwalten, die beim B2B-Messaging erforderlich sind. Obwohl das Objektmodell eine vollständige Parität für die Vorgänge anstrebt, die über das Portal verfügbar sind, gibt es einige Aufgaben, die außerhalb der Verwendung des Objektmodells ausgeführt werden. Dieser Abschnitt enthält Informationen zu den Aufgaben, die mithilfe des Objektmodells, der PowerShell-Cmdlets zum Verwalten von BizTalk Service und des BizTalk Services-Portals ausgeführt werden können.

 

  Verwenden des Objektmodells Verwenden der PowerShell-Cmdlets Verwenden des Portals

Partner erstellen

--- Profil erstellen

--- Identitäten hinzufügen

--- Zertifikat hochladen

X12-Vereinbarung erstellen

--- Partner1, Partner2 festlegen

--- Identitäten hinzufügen

--- Schema hochladen

--- Batch erstellen

X12 Bridges bereitstellen

--- Weiterleitungseinstellungen hinzufügen

--- Transformation hochladen

AS2-Vereinbarung erstellen

--- Partner1, Partner2 festlegen

AS2 Bridges bereitstellen

--- Weiterleitungseinstellungen hinzufügen

Erstellen einer EDIFACT-Vereinbarung

--- Partner1, Partner2 festlegen

--- Identitäten hinzufügen

--- Schema hochladen

--- Batch erstellen

EDIFACT Bridges bereitstellen

--- Weiterleitungseinstellungen hinzufügen

--- Transformation hochladen

Zum Abrufen der Metadaten zu TPM-OM-Entitäten können Sie einfach den Endpunkt in einem Browser aufrufen. Wenn Sie jedoch CRUD-Operationen gleich welcher Art für die Entitäten ausführen möchten, müssen Sie Nachrichten anfordern, die die erforderlichen Headerwerte sowie den Nachrichteninhalt (falls erforderlich) enthalten.

  • Sie müssen die erforderlichen Header für das Aufrufen des REST-Endpunkts mit einschließen.

    Mithilfe der TPM OM-API können Benutzer OData-basierte HTTP-Anforderungen senden, um TPM OM-Entitäten zu erstellen und Antworten im ausführlichen JSON-, Atom- und Pub- oder direktem XML-Format zu erhalten. Da die TPM OM-API den Entwurfsrichtlinien von Azure- entspricht, ist ein Satz erforderlicher HTTP-Header, die von jedem Client beim Herstellen der Verbindung zum TPM OM-API-REST-Endpunkt verwendet werden müssen, sowie ein Satz optionaler Header verfügbar. In den folgenden Abschnitten werden die Header und HTTP-Verben beschrieben, die mit der TPM OM-API verwendet werden können.

    Eine Liste der erforderlichen und optionalen Header finden Sie in den Abschnitten "HTTP-Anforderung", "HTTP-Antwort" und "HTTP-Verben" (in diesem Thema).

  • Wann immer möglich, müssen Sie die erforderlichen Eigenschaftennamen mit den entsprechenden Werten einschließen. Eine Liste der Entitäten und ihrer Eigenschaften finden Sie unter TPM OM-API: Verfügbare Entitäten und Eigenschaften.

Jeder Aufruf eines TPM OM-API-REST-Endpunkts muss einen Satz erforderlicher sowie bei Bedarf einen Satz optionaler Header umfassen. In der folgenden Tabelle werden die erforderlichen Header aufgelistet:

Erforderliche Header

 

Header Typ Wert

Autorisierung

WRAP Zugriffssteuerung-Token

Der Wert muss den Zugriffstoken umfassen, der vom Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) bereitgestellt wird. Informationen zum Abrufen eines Zugriffssteuerung-Tokens mithilfe des WRAP-Protokolls finden Sie unter http://msdn.microsoft.com/library/windowsazure/hh674475.aspx.

Host

String

Gibt den Host und die Portnummer der Zielressource an.

DataServiceVersion

Dezimal

1.0

MaxDataServiceVersion

Dezimal

3.0

x-ms-version

Dezimal

1.0

If-Match

Entitätstag

Gibt an, dass ein Vorgang nur ausgeführt wird, wenn das im Anforderungsheader angegebene Entitätstag mit dem Entitätstag des Objekts übereinstimmt.

noteHinweis
Dieser Header ist nur für Aktualisierungs- oder Löschvorgänge erforderlich.

noteHinweis
Da die TPM OM-API OData verwendet, um ihr zugrunde liegendes Ressourcenmetadaten-Repository über REST-APIs verfügbar zu machen, müssen die Header DataServiceVersion und MaxDataServiceVersion in jede Anforderung eingeschlossen werden. Andernfalls geht die TPM OM-API derzeit davon aus, dass der für DataServiceVersion verwendete Wert "1.0" ist.

Optionale Header

 

Header Typ Wert

Datum

RFC 1123 Date

Zeitstempel der Anforderung

Accept

Inhaltstyp

Der angeforderte Inhaltstyp für die Antwort. Beispiel:

  • application/xml

  • application/json;odata=verbose

  • application/atom+xml

Accept-Encoding

Gzip, deflate

GZIP- und DEFLATE-Codierung, falls zutreffend.

Accept-Language

"en", "es" usw.

Gibt die bevorzugte Sprache der Antwort an.

Accept-Charset

Ein Zeichensatztyp wie UTF-8.

Der Standardwert ist UTF-8.

X-HTTP-Method

HTTP-Methode

Gestattet es Clients oder Firewalls, die HTTP-Methoden wie PUT oder DELETE nicht unterstützen, diese Methoden zu verwenden, die über einen GET-Aufruf einbezogen werden.

Content-Type

Inhaltstyp

Der Inhaltstyp des Anforderungstexts in POST- und PUT-Anforderungen.

Nachfolgend ist ein Satz von Headern aufgeführt, die in Abhängigkeit von der angeforderten Ressource und der auszuführenden Aktion möglicherweise an Sie zurückgegeben werden.

 

Header Typ Wert

Datum

RFC 1123 Date

Das Datum, an dem die Anforderung verarbeitet wurde.

Content-Type

Variiert

Der Inhaltstyp des Antworttexts.

Content-Encoding

Variiert

Gzip oder deflate, nach Bedarf

Cache-Control

-

Gibt an, ob das Objekt von Cachemechanismen, von Server bis Client, zwischengespeichert wird.

Content-Length

Inhaltstyp

Die Länge des Antworttexts.

Server

-

Ein Servername.

X-Content-Type-Options

Inhaltstyp

Der einzige zulässige Wert "nonsniff" verhindert, dass Browser die MIME-Ermittlung für Antworten mit dem deklarierten Inhaltstyp ausführen.

Nachfolgend finden Sie eine vollständige Liste von HTTP-Verben, die von der TPM OM-API unterstützt werden und beim Erstellen von HTTP-Anforderungen verwendet werden können:

 

VERB Beschreibung

GET

Gibt den aktuellen Wert für eine Entität wieder.

POST

Erstellt auf Basis der bereitgestellten Daten ein Objekt (oder übermittelt einen Befehl).

PUT

Ersetzt ein Objekt oder erstellt ein neues Objekt (falls zutreffend).

LÖSCHEN

Löscht ein Objekt.

MERGE

Aktualisiert ein vorhandenes Objekt mit benannten Eigenschaftsänderungen.

Da die TPM-OM-API auf dem OData-Protokoll basiert, können Sie die WCF Data Services zum Erstellen von .NET-Anwendungen, die CRUD-Operationen für die Entitäten ausführen, verwenden. Weitere Informationen zum Erstellen von .NET-Anwendungen mithilfe der TPM-OM-API finden Sie unter Erstellen von .NET-Anwendungen mit der TPM OM-REST-API.

Siehe auch

Anzeigen: