Suche im Requests View durchführen 

Vorgehensweise

...

       1.      Um eine Suche durchzuführen, markieren Sie einen Buildspace.

       2.      Geben Sie Suchattribute ein.

       3.      Wählen Sie Search.

Es gibt unterschiedliche Arten zu suchen. Einzelheiten zu den Suchmodi finden Sie unten.

Simple Search (Einfache Suche)

In diesem Register suchen Sie nach Requests anhand der Request-ID.

Advanced Search (Erweiterte Suche)

Suchen Sie in diesem Register nach weitläufigeren Optionen wie Request-Status, Request-Typ, Anlegezeit und Besitzer der Requests.

Filterlisten

In den Views ‘Open’ Requests und Completed (Unconfirmed) Requests verwenden Sie Filter, um die gewünschten Objekte zu suchen.

...

...

       1.      Um eine Suche durchzuführen, markieren Sie einen Buildspace.

       2.      Geben Sie Filterattribute ein.

       3.      Wählen Sie Filter.

Open Requests (Offene Requests)

Suchen Sie mit diesem Register nach Requests, die in der Warteschlange stehen, aber noch nicht verarbeitet werden.

Completed (Unconfirmed) Requests (Abgeschlossene (unbestätigte) Requests)

Suchen Sie mit diesem Register nach abgeschlossenen Requests, die in der Warteschlange stehen (z.B. für automatisches Deployment), aber von dem Service, der die Build-Ergebnisse in Anspruch nimmt, noch nicht bestätigt wurden. Dies ist nur möglich, wenn der Output Queue Mode auf QUEUED gesetzt ist.

Im Ergebnisbereich werden die gefundenen Requests angezeigt. Für jeden Request werden die folgenden Eigenschaften angezeigt:

·        Request ID:

Die Request-ID wurde beim Anlegen vergeben.

Request-Nummern werden in aufsteigender Reihenfolge vergeben, aber es kann Lücken in der Reihenfolge geben.

·        Request State:

¡        SUCCEED: Der Build wurde erfolgreich abgeschlossen.

¡        FAILED: Der Build wurde mit Fehlern abgeschlossen.

¡        NEW: Der Request wird gerade angelegt und wurde noch nicht in die Request-Warteschlange eingereiht.

¡        QUEUED: Der Request ist bereit zur Verarbeitung.

¡        PROCESSING: Der Request wird gerade verarbeitet.

¡        WAITING: Manchmal benötigt ein Request den Build von DCs, die andere DCs verwenden, die bereits in einem anderen Request zum Build eingeplant sind. In diesem Fall wird der Request in den Zustand WAITING gestellt, bis die verwendeten Komponenten gebaut sind.

¡        CANCELED: Der Request wurde vom Besitzer oder von einem Administrator abgebrochen.

¡        INVALID: Der CBS-Service hat festgestellt, dass der Request ein schlechtes Format enthält, das nicht verarbeitet werden kann.

¡        SUSPENDED: Der Request wurde vom Besitzer oder von einem Administrator explizit ausgesetzt.

·        Request Type:

¡        INIT_COMPARTMENT: Ein Request zur Initialisierung eines Compartment aus DTR-Inhalt, der entweder explizit von einem Administrator plaziert oder implizit vom CBS angelegt wurde, während der Buildspace angelegt wurde.

¡        IMPORT: Aktivierung von importiertem DTR-Content oder Import von Archiven, die an anderer Stelle angelegt wurden. Requests dieses Typs werden angelegt, wenn ein Import über CMS stattfindet.

¡        INTERNAL_BUILD: Der Request wurde vom CBS angelegt, um einen neuen Build mit Komponenten zu starten, nachdem eine verwendete Komponente geändert wurde.

¡        ACTIVATE: Ein Aktivierungs-Request von einem Entwickler.

¡        DC_BUILD: Ein von einem Benutzer in der Web UI angelegter Build-Request.

·        Owner:

Der CBS-Benutzer, der den Request angelegt hat.

·        Confirmed:

Gibt an, ob die Ergebnisse dieses Build-Requests bereits bestätigt oder in der Ausgabewarteschlange abgelegt wurden.

Je nach Zustand des Request kann ein Administrator oder der Besitzer des Requests folgende Aktionen mit dem Request durchführen (ein leeres Feld gibt an, dass die Aktion für diesen Zustand des Request nicht durchgeführt werden kann, ein ’X’ gibt an, dass die Aktion für diesen Zustand durchgeführt werden kann):

Mögliche Aktionen für einen Request, abhängig von seinem Zustand

Aktion	Neu	Warteschlange	Ausgesetzt	Erfolgreich
Bestätigen				X
Abbrechen	X	X	X
Wiederaufnehmen			X
Aussetzen		X

Ist ein Request in einem Zustand, in dem eine bestimmte Aktion nicht möglich ist, dann ist die Taste für diese Aktion deaktiviert.

In den Registern unten im Bild finden Sie Detailinformationen zum ausgewählten Request.

·        Request-Details:

¡        Request-ID: Die Request-ID wurde beim Anlegen vergeben.

¡        Created at: Zeit, zu der der Request angelegt wurde.

¡        Finished at: Zeit, zu der die Verarbeitung des Request abgeschlossen wurde.

¡        Request log URL: Ein Link zum Protokoll für den gesamten Request. Dies ist ein Übersichtsprotoll, das Informationen zu Request-spezifischen Aktionen enthält, die zu keiner der Development Components zugeordnet werden können, die im Zusammenhang mit diesem Request gebaut wurden.

¡        Parent-Request ID: Die Request ID des Build-Requests, der den gerade gewählten Request ausgelöst hat (der Wert ist Null, wenn keine Parent-Request ID existiert).

·        Follow up requests:

Liste der Requests, die angelegt wurden, um Development Components neu zu bauen, die von den Komponenten abhängen, die durch den aktuellen Request geändert werden.

·        Request DCs:

Listet die Development Components, die mit diesem Request gebaut/importiert werden sollen.

·        Request Results:

¡        Zeigt eine Zeile für jede Build-Variante jeder Development Component, die während der  Verarbeitung dieses Request gebaut wurde.

¡        Die Ampel zeigt, ob der Request erfolgreich war (grün) oder fehl schlug (rot) oder noch verarbeitet wird (gelb).

¡        Die Spalte deployable zeigt ein grünes Plus, wenn der Build dieser Variante der Komponente Ergebnisse produzierte, die direkt in die Ziel-Laufzeitumgebung eingespielt werden können. Ansonsten erscheint hier ein rotes Minus. Beachten Sie, dass dies kein Fehler ist. Viele Arten von Development Components erzeugen niemals deploybare Ergebnisse (z.B.: Java DCs, Web Modules, EJB Modules usw.).

¡        Build log: Diese Spalte enthält ein Link auf das Build-Protokoll, das für den Build dieser Variante der Development Component geschrieben wurde. In diesem Protokoll finden Benutzer die Fehlernachtichten, wenn ein Build wegen eines Syntaxfehlers im Java-Code fehl schlägt.

·        Parked Requests:

¡        Listet die Build-Requests auf, die gerade auf diesen Build-Request warten.

·        Waiting Requests:

¡        Listet die Build-Requests auf, die auf diesen Build-Request warten.