Searching Activites

Searching in the Activities View

1. Start the CBS Web UI and select the Activities view.

2. To perform a search, select a buildspace.

3. Select a compartment.

4. Set search attributes.

5. Choose Search .

There are different ways to search. Details regarding the search modes are given below.

Simple Search

Simple search is based on:

Advanced Search

Advanced search is based on:

Pending Activities

Use this view to select all the activities that are checked in or integrated into the inactive workspace but not activated yet. You can restrict the search by specifying a DTR user name as the owner of the activities.

An administrator can choose to activate a pending activity for which there are two choices:

• Activate

• Activate even if build fails

If you activate an activity even though the build fails, the affected development components will have status "broken".

Activated Activities

Use this view to select only already activated activities.

In all tab strips the activity details for the selected activity are displayed in the region at the bottom of the screen.

Searching in the Requests View

1. To perform a search, select a buildspace.

2. Set search attributes.

3. Choose Search .

There are different ways to search. Details regarding the search modes are given below.

Simple Search

Use this tab strip to search for a request based on request ID.

Advanced Search

Use this tab strip for searching on broader options like request status, request type, request creation time and owner of requests

Filter Lists

In the 'Open' Requests and Completed (Unconfirmed) Requests , you use filters to find the objects you need.

1. To perform a search, select a buildspace.

2. Set filter attributes.

3. Choose Filter .

   • Open Requests

     Use this tab strip to search for requests that are in the queue not processed yet.

   • Completed (Unconfirmed) Requests

     Use this tab strip to search for completed requests that are queued (e.g. for automatic deployment) but not confirmed yet by the service that consumes the build results. This can only happen if the output queue mode is set to QUEUED.

     In the results area the found requests are displayed. For each request the following properties are displayed:

     • Request ID:

       The ID that was assigned to the request when it was created.

       Request numbers are assigned in ascending order but there can be gaps in the sequence.

     • Request State:

       • SUCCEED: The build was completed successfully.

       • FAILED: The build completed with errors.

       • NEW: The request is being created and not even inserted into the request queue.

       • QUEUED: The request is ready to be processed.

       • PROCESSING: The request is currently being processed.

       • WAITING: Sometimes a request requires building some DC that uses other DCs, which are already scheduled for, build in some other request. In this case the request is put into WAITING state until the used components are built.

       • CANCELED: The request was cancelled by the owner or by an administrator.

       • INVALID: The CBS service detected that the request has a bad format cannot be processed.

       • SUSPENDED: The request was explicitly suspended by the owner or by an administrator.

     • Request Type:

       • INIT_COMPARTMENT: A request to initialize a compartment from DTR content either explicitly placed by an administrator or implicitly created by CBS during creation of the buildspace.

       • IMPORT: Activation of imported DTR content or import of archives that were created somewhere else. Requests of this type are created when an import is done via CMS.

       • INTERNAL_BUILD: The request was created by CBS to rebuild using components after a used component was changed.

       • ACTIVATE: An activation request placed by a developer.

       • DC_BUILD: A build request created by a user in Web UI.

     • Owner:

     • Confirmed:

       Indicates whether the results of this build requests are already confirmed or stored in the output queue.

       Depending on the state of the request, an administrator or the owner of the request can perform the following actions on the request (an empty field indicates that the action cannot be performed for that state of the request, the 'X' indicates that the action can be performed for that state of the request):

Possible Actions on a Request Depending on Its State

• Request details:

  • Request ID: the ID that was assigned to the request when it was created.

  • Created at: The time when the request was created.

  • Finished at: The time when processing of the request was finished.

  • Request log URL: A link to the log for the whole request. This is a summary log that contains information about request specific actions that cannot be assigned to one of the development component that were built in the context of this request.

  • Parent Request ID: The request ID of the build request that triggered the currently selected request (the value is 0 if no parent request ID exists).

• Follow up requests:

  Lists the request that were created to rebuild development components that depend on the components that were changed by the current request

• Request DCs:

  Lists the development components that are/were to be built/imported in the context of this request

• Request Results:

  • Shows one line for each build variant of each development component that was built during processing of this request.

  • The traffic light displays whether the request was successful (green) or failed (red) or is still being processed (yellow).

  • The deployable column shows a green plus sign if the build of this variant of the component produced results that can be directly deployed into the target run-time environment. Otherwise a red minus sign is shown. Note that this would not be an error. Many types of development components never create deployable results (e.g.: Java DCs, Web Modules, and EJB Modules etc).

  • Build log: This column contains a link to the build log that was written for the build of this variant of the development component. This is the log where users would find the error messages if a build failed because of a syntax error in the Java code.

• Parked Requests:

  • Lists the build requests that are currently waiting for this build request.

  • Waiting Requests:

  • Lists the build requests that are waiting for this build request.