Status Aktueller Status
BUYER_IN_WORK oder SELLER_COMMIT

Der SellerSync ist ein Feature, welches dem Seller ermöglicht, in den Buchungsprozess einzugreifen. Der SellerSync kann genutzt werden, um Änderungen an Spots vorzunehmen oder Spots zu stornieren. Dabei kann der Buyer nicht blockiert werden, da die Anzeige automatisch aktualisiert wird. Ein SellerSync kann nur dann durchgeführt werden, wenn keine “normale” Buchung für das betreffende SellerProduct vorliegt, d.h. wenn sich der letzte Request nicht im Status BUYER_COMMIT oder SELLER_IN_WORK befindet. Wenn der SellerSync unzulässig durchgeführt wird, wird eine Fehlermeldung zurückgegeben.

Es gibt es zwei Szenarien (die auch gleichzeitig auftreten können), unter denen der SellerSync ausgeführt werden kann:

  1. Einerseits, wenn eine Bearbeitung durch den Seller zu diesem Zeitpunkt nicht vorgesehen ist, d.h. der Vorgang nicht den Status SELLER_IN_WORK hat. (Der Buyer muss hierfür keinen neuen Request stellen)
  2. Andererseits kann der SellerSync durchgeführt werden, wenn das angeforderte SellerProduct nicht mehr lieferbar ist. Der Buyer muss dafür dieses SellerProduct nicht anfragen.

Dabei kümmert sich die Plattform darum, dass die entsprechenden Requests und Answers geschrieben werden.

Warning Warnung:
Nur in den genannten Fällen soll der Seller vom SellerSync Gebrauch machen. Ansonsten soll standardmäßig wie im Workflow-Beispiel beschrieben die Answer angelegt werden!

Voraussetzungen

Der Seller muss sicherstellen, dass im SellerSync für ein SellerProduct alle gebuchten Spots dieser planElementId vorhanden sind. Dies wird nicht durch die audioXchange-Plattform geprüft!

Warning Warnung:
Alle gebuchten Spots für ein SellerProduct des betroffenen PlanElements müssen im SellerProductAnswerInput mitgeliefert werden!

Um einen SellerSync durchzuführen, muss der SellerSyncInput mit der planElementId und den SellerProduct-Antworten ausgefüllt werden. Der SellerProductAnswerInput enthält Informationen zu jedem betroffenen SellerProduct, einschließlich der Answer und des Sync-Grundes. Nachdem die SellerSync-Mutation gesendet wurde, wird die Anzeige automatisch aktualisiert, ohne den Kaufprozess für den Buyer zu blockieren. Es wird automatisch der Status auf SELLER_COMMIT gesetzt.

Die audioXchange-Plattform wird in jedem Fall mindestens einen neuen Request erstellen, wenn nötig aber auch einen neuen RequestStream.

Die verschiedenen Möglichkeiten, die als Sync-Grund angegeben werden können, werden im SellerSyncReasonType definiert:

  • FORCE_MAJEURE
  • JUDICIAL
  • ON_BOARDING
  • OTHER
  • NONE

Die Mutation für den SellerSync lautet wie folgt: sellerSync(input: SellerSyncInput!): SellerPlanElement!

Insgesamt ist der SellerSync ein nützliches Feature für Vermarkter, die Änderungen an Spots vornehmen oder Spots stornieren müssen, ohne den Kaufprozess für den Buyer zu blockieren.

Konsequenzen

Durch den SellerSync wird der Status automatisch auf SELLER_COMMIT gesetzt, damit der Buyer auf diese Weise nicht blockiert wird.

Warning Warnung:
Der SellerSync ist ein Prozess, der besondere Vorsicht benötigt.

Alle betroffenen Requests werden - egal welchen Status sie gerade haben - beendet!

Es ist wichtig zu beachten, dass jede Änderung des Buyers, die noch nicht vom Seller abgerufen wurde, durch den SellerSync verloren geht.

Beispiele

Spezielle GraphQL-Typen

CampaignBuyerQuery

Requests geben nun keinen konkreten Typen mehr zurück, sondern das Interface BuyerRequestResult. Das Interface enthält Felder, die in allen Typen, die dieses Interfaces implementieren, vorkommen müssen.

BuyerRequestResult kann entweder vom Typ BuyerRequest oder SellerSyncRequest sein. Siehe auch Request

Beispiel-Query

query {
  campaignBuyer {
    request(id: "xxxxxxxx-requestId-xxxxxxxxxxxx") {
      __typename
      id
      rowVersion
      ...on BuyerRequest {
        requestSpots {
          id
          rowVersion
          parts {
            id
            index
            dspKey
            lengthWithoutOtc
          }
        }
      }
    }
  }
}

CampaignSellerQuery

Requests geben nun keinen konkreten Typen mehr zurück, sondern das Interface SellerRequestResult. Das Interface enthält Felder, die in allen Typen, die dieses Interfaces implementieren vorkommen müssen.

SellerRequestResult kann entweder vom Typ SellerRequest oder SellerSyncRequest sein.

Beispiel-Query

query {
  campaignSeller {
    request(id: "xxxxxxxx-requestId-xxxxxxxxxxxx") {
      __typename
      id
      rowVersion
      ...on SellerRequest {
        requestSpots {
          id
          rowVersion
          parts {
            id
            index
            dspKey
            lengthWithoutOtc
          }
        }
      }
    }
  }
}