UI Overview

This section includes detailed description of all pages and dialog boxes in DevOps.

1. Tickets page

At least one landscape has to be created. See this page to learn how to create landscape.

Tickets page shows all existing tickets and looks:

tickets

Ticket ID is generated automatically based on the prefix and corresponding incremented number. Prefix can be configured through irt.config.ticket-id-prefix parameter (see Figaf Tool application running for more details).

On this page you can:

  1. Create new ticket clicking on Create Ticket button. It opens 'Create new ticket' dialog box, where the following options can be set:

    1. Title of the ticket. The same title can be used for several tickets.

    2. Release defines release, to which created ticket will be attached. See release page for details about release.

    3. Assignee defines the user, to whom the ticket will be assigned.

    4. Type defines type of new ticket. Since 2.11 release the following ticket types are available:

      1. Development is used with development within one landscape.

      2. Migration is used when it is needed to migrate objects from one landscape to another.

    5. Landscape defines a landscape for development ticket. See Landscapes page for details about landscapes.

    6. Source Landscape, Target Landscape, and Migration Landscape define landscapes for migration ticket. Defined landscapes have to satisfy the following:

      1. Source Landscape and Target Landscape have the same count of Agents (Landscape items) and do not have shared Agents.

      2. Migration Landscape must consist of two items: the 1st items from Source Landscape and Target Landscape correspondingly.

    7. External ticket id identifies an external ticket (e.g. in Jira).

    8. External ticket link defines a link on the external ticket. If you define the value, you can navigate directly to the external ticket from Figaf Tool.

    9. Description defines additional information.

    Related test suite Test Suite: Test cases for ticket <Ticket ID> is created and linked with new ticket.

  2. Select existing ticket(s) and delete it(them) clicking on red trash button.

    Tickets attached to any release can’t be deleted. If you want to delete such tickets, you have to detach the tickets from the release and after that delete them.

  3. View a ticket details clicking on its details button. It opens ticket page.

  4. View linked release details clicking on <Release Title>. It opens release page.

2. Ticket page

Ticket page shows the ticket details and provides functionality for ticket management. It looks:

ticket details

There are the following tabs on this page:

On each tab you are able to:

  1. Open another ticket details clicking on open another button and selecting a ticket.

  2. View linked release details clicking on <Release Title>. It opens release page.

  3. Move the ticket to next or previous stages depending on its type:

    1. Development is used with development within one landscape.

    2. Migration is used when it is needed to migrate objects from one landscape to another.

Development and Migration ticket types provide similar workflow with small differences:

  • Development tickets have the following statuses:

    • In development is the stage when objects are attached, updated, detached from the ticket.

    • In transport is the stage when development part is done, operations available on In development stage are blocked, objects are prepared for transport through the landscape. If the landscape has Integrated transport management, transports with objects attached to the ticket will be created automatically. Otherwise, if Integrated transport management is false, user needs to attach transports to the ticket. Ticket can be resolved only if all related active transports are imported (see Transport Statuses for details).

    • Completed is the stage when transport stage is successfully completed, the ticket is marked as Completed. It means that all objects are available and operational on all systems in the landscape.

    • Canceled is finish stage if ticket can’t be resolved due to any reason.

      The picture below shows development ticket status transitions:

      development ticket diagram

  • Migration tickets have the following statuses:

    • Prepared is the stage similar to In development.

    • In development is the same as for development ticket, but for migration ticket we assume that changes will not be done with source objects because the main goal for migration is to migrate objects between landscapes, it is not about their changes in the old landscape.

    • In transport is the same as for development ticket.

    • Migrated is the stage when transport stage is successfully completed, the ticket is marked as Migrated. It means that all objects are available and operational on all systems in the landscape. It is possible to process development ticket creation and transport configuration copying on that stage.

    • Canceled is finish stage if ticket can’t be resolved due to any reason.

      The picture below shows migration ticket status transitions:

      migration ticket diagram

  1. Ticket Details tab provides ticket details updating. See almost all ticket properties here. Additional properties:

    1. Depends on tickets

    2. Dependent tickets

      Landscape (for development ticket), Source Landscape, Target Landscape, and Migration Landscape (for migration ticket) can’t be modified.

  2. Tracked Objects tab provides functionality for attached tracked object management:

    ticket tracked objects

    Here you can:

    1. Attach Tracked Objects clicking on Attach Tracked Objects button. It opens 'Attach tracked objects to ticket' dialog box with predefined Agent: for development ticket - the first item from target landscape, for migration ticket - the first item from migration landscape. So it is possible to manually attach only development objects.

      Attaching objects should be licensed for DevOps or Migration (see Configure Object Licenses for details).

      All object versions in the table are the latest.

      If the object has been already selected, it is not visible in the table, but you can see the count of such objects.

      Previous object version becomes detached.

    2. Update selected object(s) to the latest version clicking on Update to the latest version. It attaches the latest version of chosen object(s) to the ticket (versions are looked up in CTT).

    3. Attach all dependent objects of selected object(s) clicking on Attach all dependent objects. It attaches the latest versions of all child dependencies of chosen object(s) recursively.

      For channels, it gets a parent link to component/system and then again parent link to the party.

    4. Detach selected Tracked Objects clicking on Detach Tracked Objects. It marks chosen object versions in the ticket as detached (versions are still visible in the table) if Detach Only option is selected. It deletes chosen object versions from the ticket if Delete Links option is selected.

    5. Compare versions of two selected objects clicking on Compare Versions. It opens 'Tracked Object Differences' dialog box with two selected object versions.

      These objects must have the same type in the change tracking.

      BPMN model and Simplified model can be compared for integration flows.

    6. Start synchronization on chosen Agent clicking on Synchronize (read about synchronization here).

      It is possible to select Agents which are used in related landscape(s).

    7. View tracked object details clicking on its Name. It opens 'Name page' with tracked object details.

  3. Test Cases tab provides functionality for test case management and looks:

    ticket test cases

    Here you can:

    1. Add/remove recommended test cases clicking on Lookup related Test Cases. It opens 'Assign Test Cases To Ticket' dialog box, where you can select test cases recommended for adding or removal:

      assign test cases to ticket

      Test cases recommended for adding are test cases related to the attached ICOs, Sender Agreements, CPI Iflows, B2B Scenarios tracked objects.

      Test cases recommended for removal are previously added test cases related to the detached from the ticket ICOs, Sender Agreements, CPI Iflows, B2B Scenarios tracked objects.

    2. Open related test suite clicking on Open Test Suite. It opens Test Suite page.

    3. Detach selected test cases clicking on Detach from Ticket. It triggers test case detaching operation from test suite.

    4. Run the related test suite clicking on run or run on buttons:

      • Run uses static links to test objects defined in the test case.

      • Run on resolves these links dynamically at the moment of test run. It is possible to see how these links are resolved through Current Mapping Configuration button - it opens 'Mapping Configuration' dialog box:

        mapping configuration

        There are Agent Objects (parent nodes) and Test Objects (child nodes) in opened dialog box.

        You can’t run test suite without linked test cases.

  4. Last Testing Result tab shows results of last running. On this page you can:

    1. View Agent and Test Objects clicking on Agent Object Title or Test Object Title. It opens Integration Object Details page.

    2. Poll remote results clicking on Poll remote results.

      Since Figaf Tool 2.15 automatic polling is added for SAP CPI Agents. Once the messages have been run successfully, automatic polling is started.

      Since Figaf Tool 2.15.2 active polling statistics can be viewed. If there is polling in progress for the integration objects and you open another poll remote data dialog, then

      • recordings/test runs which are in both polling requests will be marked as SKIPPED_AS_DUPLICATE and statistics will be copied from original item and shown on UI in the new one.

      • recordings/test runs which are not in the original polling request will be SKIPPED in the new one.

      Since Figaf Tool 2305 polling will not be started if there is already a started polling requests with same objects in progress or polling has been already completed for all selected objects.

      If you have polled almost all messages and you just need to poll small number of messages to finish testing, you can enable option Ignore messages cache during polling on Application configuration page. When this option is enabled, already polled messages won’t be skipped. It affects performance when the amount of messages is large and you just need to poll small number to finish testing.

    3. View last polling result clicking on Open Last Polling Result.

      Open Last Polling Result button is available after polling remote data and until page is refreshed.

    4. Export as a test case to PIT (only for PRO) clicking on Export as a Test Case to PIT.

      Export as a Test Case to PIT is available only for licensed version after the test suite running.

    5. Compare testing results and build reports clicking on check button.

      The option reprocesses comparison and report generation asynchronously. It makes sense to execute the option once you have configured a new "ignore rule".

    6. Do the following actions clicking on menu and choosing corresponding option:

      1. Rerun reruns required test case.

      2. View testcase opens 'Test Case Details' page.

      3. Download report.

        Report type can be one of 2 types:

        1. xlsx report:

          • Contains information about test run/test suite run results.

          • By default only failed results are added to xlsx report. If you want to change this behavior, go to Configuration → Application page and enable Show successful messages in the test suite’s report property.

        2. zip archive with 3 csv reports:

          • test-run-metadata.csv - contains common information about test run/test suite run (e.g. test object, counters for success/error/unexpected/not/compared/unfinished test run/test suite run results).

          • diff-report.csv - contains diff report for test run/test suite run.

          • processed-messages-report.csv - contains processed messages report for test run/test suite run.

        The report type is defined from Use bundled CSV report generation strategy property configured on Application configuration page. If it’s true, the report type is zip, otherwise, it’s xlsx.

      4. View results opens Test Run Details page.

  5. Alerts tab shows alerts attached to the ticket.

  6. Transports tab shows linked transports (see transport page for details about transports) and looks:

    ticket transports

    Here you can:

    1. View transport details clicking on its details button. It opens transport page.

    2. Delete selected transports clicking on red trash button.

  7. Reports tab contains built reports and looks:

    ticket reports

    Here you can:

    1. Build new report clicking on Report button. It starts report building and new row is added to the table (with IN PROGRESS status). To get built report wait for a while and click on Refresh button.

    2. Download built xlsx report clicking on report button.

    3. Delete a report clicking on its decline button.

  8. Transports Overview shows relationship between tickets and transports in CPI and Api Management composite landscapes so that it clarifies how the set of transports has been done in the history.

    Include lookup by transported object version enables browsing of other graphs that also cover the source objects state in the current ticket.

3. Transports page

Transports page shows all created transports and looks:

transports

Transport ID is generated automatically based on the prefix and corresponding incremented number. Prefix can be configured through irt.config.transport-id-prefix parameter (see Figaf Tool application running for more details).

On this page you can:

  1. Switch between tabs:

    1. All transports to view all existent transports.

    2. My Approvals to view transports in WAITING_FOR_APPROVAL status and current user is reviewer for them.

    3. My Actions to view transports in CREATED, WAITING_FOR_APPROVAL, or IN_PROGRESS statuses which can be performed by current user. The following is available on this page:

      1. Import several transports in batch mode.

        Batch import is supported for all CPI/Api Management transports linked with binary landscape and only for Integration Directory transports linked with PI binary landscape. Batch import is not supported for groups of transports (when multiple transports created for one ticket).

        Once several transports are imported in batch mode, they are linked by batchId and can be rollbacked only in batch mode from transport page of one of this linked transports. Batch rollback feature has some limitations that you can read here. If transports are linked by batchId, transitions of related tickets statuses are executed together (see ticket status transitions here).

      2. Schedule transports which are ready for import and linked with binary landscape. Be sure to configure appropriate Scheduled transports execution time on Landscape configuration page.

        Only independent transports (i.e. without shared objects) should be scheduled for import.

      3. Disable schedule for transports.

  2. View linked tickets of required transport clicking on its menu full button. You also can open the ticket details page clicking on 'Ticket ID: Title'. It opens ticket page.

  3. View a transport details clicking on details button. It opens transport page.

  4. Select transport(s) and delete it(them) clicking on red trash button.

4. Transport page

Transport: Name page shows the transport details and looks:

transport details

On this page you can:

  1. View transport configuration of the transport item clicking on its configuration button. It opens Transport Configuration page with preselected Landscape and Tracked Object.

  2. Check estimated payload that will be created on the target landscape after migration clicking on its check full button. It opens 'Compare' dialog box:

    compare

  3. Compare imported version with previous version on target system for imported transports clicking on its check full button. It opens 'Compare' dialog box:

    compare

  4. View linked ticket details clicking on the ticket title. It opens ticket page.

  5. View details of transports from the same group clicking on the transport ID. It opens the same page with different data.

  6. Validate transport configuration clicking on Validate Transport. It validates dir objects mapping and password settings:

    1. If a component is mapped from X to Y, but channel from X|ChannelName to Z|ChannelName, it shows an error about inconsistent mapping.

    2. If the password parameter has a static value config, its value shouldn’t be empty if it’s not empty on the source system. If the password parameter is inherited from target, target object should exist.

      Validate Transport is available only for transport with INTEGRATION_DIRECTORY registry type until the transport is approved or imported.

      Transport configuration validation is processed automatically during transport creation, approval (if Require Transport Approval option is true on the landscape), import.

  7. Create Transport with the latest versions (for CPI and Api Management). The operation cancels current transport and create a new one with the latest objects versions (the versions should be synchronized).

  8. Create next Ticket (available only for composite landscapes if landscape related to current transport has 1 successor).

  9. Download traces of the last import (for imported/reverted transports). The traces contain progress info of the transport.

    For PI transports import details are traced only for integration directory transports with integrated transport management. Other PI cases are not traced with details, but common process related logs are there.

    Traces example:

    Started import at 17-06-2022 12:42:39 +0300 by [email protected] (admin)
Initial synchronization of T75 took 8400 ms
Initial synchronization of D75 took 8999 ms
Processing import of missing directory folders
Import of missing directory folders is completed
Processing upload of 1 Integrated configuration objects to changelist for transport
1/1: processing transport of Integrated configuration *|*|irttestDummy|http://figaf.test.com||
1/1: processed in 1134 ms, transport is skipped because target object with needed state already exists
Upload of 1 Integrated configuration objects to changelist is completed in 1135 ms
Transport of 1 directory objects is completed in 23629 ms

  10. View changes overview for ICOs, communication channels, scenarios, parties, business components, business systems, sender and receiver agreements (available only if landscape related to current transport of integration directory objects is PI binary landscape). It opens Transport changes overview page where you can browse the changes and export table data to CSV format.

  11. Download parameters report that contains all external properties that are used in the transport (only for binary landscapes). It supports CPI IFlows (CPI platform), communication channels (PRO platform) and API Proxies and Key Value Maps (Api Management platform).

  12. Batch parameters update to upload transport configuration parameters for several objects in scope of the landscape in the transport (only for binary landscapes). You need to prepare .csv file (the structure of data should be equal to the structure of downloaded parameters report). Then upload the file, check changes and submit them. It supports CPI IFlows (CPI platform), communication channels (PRO platform) and API Proxies and Key Value Maps (Api Management platform). Go to Batch parameters update for more details.

  13. Schedule transport for import. Go to Schedule import for more details.

  14. Disable schedule import for transport.

  15. Display Design Guidelines for CPI transports with IFlows.

  16. Migrate passwords (for PRO) clicking on Migrate passwords if possible.

    Migrate passwords if possible is available only for transport with INTEGRATION_DIRECTORY registry type, containing at least one channel, and linked with migration ticket until the transport is approved or imported.

  17. Manage the transport statuses:

    1. CREATED is initial state for transport if Require Transport Approval option is true on the landscape, import and approval operations are not available at this stage.

    2. WAITING_FOR_APPROVAL is state when transport has not been approved yet, import operation is not available. You can import transport, decline it, or soft decline (for PRO binary landscape). Soft decline moves transport to the CREATED state.

      Since 2509 the transport can be assigned by the reviewer (Start Review action). Reviewer marks the transport when he/she starts review. Assigned reviewer value could be used for transports filtering afterwards.

    3. IN_PROGRESS is initial state for transport if Require Transport Approval is false, and the next state for approved transport. Import operation is available only if it’s initial state for transport or all transports from the same group have been approved.

    4. IMPORTED is state when all transport items have been successfully imported on the latest landscape item.

      If for corresponding landscape Restrict Execution is true, only executors can import transport.

      Otherwise, any user with IRTDevOpsOperator, IRTDevOpsManager or IRTAdmin role can import objects.

    5. REVERTED is state when some transport items have been rollbacked to the previous landscape item state.

      Rollback feature has several limitations:

      • PRO:

        • File/CTS+ transports aren’t supported.

      • CPI:

        • If package is created by transport and there aren’t other objects in the transport, then package isn’t deleted during rollback.

        • If only IFlow configuration is changed during import (IFlow isn’t changed), then IFlow configuration isn’t reverted during rollback.

      • Api Management:

        • Encrypted key value maps aren’t supported.

      • Transport can be rollbacked if target objects state is the latest.

      • Transport is still active.

      If for corresponding landscape Restrict Execution is true , only executors can rollback transport.

      Otherwise, any user with IRTDevOpsOperator, IRTDevOpsManager or IRTAdmin role can rollback objects.

    6. DECLINED is state when transport has been declined by reviewer. It means the ticket should be moved to previous stage (to development) and transports have to be created again (automatically or manually), otherwise, import operation is not available for all transports from the same group.

    7. CANCELED is state when the related ticket has been moved to previous stage (to development) and transport has not been imported. It means the ticket should be moved to previous stage (to development) and transports have to be created again (automatically or manually), otherwise, import operation is not available for all transports from the same group.

      If for corresponding landscape Restrict Execution is true, only executors can rollback transport.

      Otherwise, any user with IRTDevOpsOperator or IRTAdmin role can cancel transport.

      The picture below shows transport status transitions:

      transport diagram

5. Transport Configuration page

Transport Configuration page shows the transport configuration of selected object on selected landscape and looks:

transport configuration

Transport Configuration is validated during opening, and validation errors are shown in warning message, e.g.:

tc validation errors

On this page you can do the following:

  1. Configure whether object is transportable or not. If Deny transport of current object is enabled, the object will not be attached to tickets and transports.

  2. Navigate between Transport Configurations of parent and child objects with transport configuration.

  3. Navigate between Transport Configurations of the same object across the Composite landscape.

  4. Browse child objects name mapping lookup for binary landscapes.

  5. Configure parameters. There are 3 possible cases for transport configuration parameters:

    1. Parameter value should be taken from source object version and set on the target object. Default behavior for all non-password parameters.

    2. Parameter value should be kept from target object version, so, it won’t be updated. Default behavior for all password parameters.

    3. Parameter value should be configured manually for chosen target system.

Transport configuration is configured differently for varied objects:

  • PRO objects:

    For parties, components, systems, communication channels, and ICOs it’s possible to configure name mapping. For communication channels it’s also possible to configure adapter specific attributes and module parameters. You also can configure mappings and switch on/off Use scenario mapping option for PRO non-binary landscapes.

    You can browse changes between source ICO state and the state to upload clicking on Changes overview button on ICO transport configuration page for PRO binary landscapes.

    Routing conditions can be configured for receivers and interfaces on ICO transport configuration page for PRO binary landscapes:

    receivers interfaces routing conditions

    By default, condition is taken from object payload. If Inherit (source) is disabled, routing condition can be changed and this new condition will be used during transport. If it’s required to reuse condition from target object for the same rule, then use ignoring option of Receivers/Interfaces projection settings.

    For receiver interface rules it’s not possible to have projection option (exclude or ignore) and manually defined condition at the same time.

    The feature has restrictions and limitations. Please consider the following:

    Receiver rule is identified by key <operation> + <receivers party and service> and that one rule can contain multiple receivers. Receiver interface rule is identified by key <receiver party and service> + <operation> + <operation mapping> + <interfaces>.

    While all rules have unique keys and they stay immutable (i.e. no changes in receivers list for receiver rule or interfaces list in receiver interface rule) - identification can be done without any problems, but when there are multiple rules with the same key or when some rule’s key is updated during source object update, we have troubles with matching previously manually configured condition with the updated set of rules. To summarize:

    1. If transport configuration has a persisted condition but related key is not found in the actual list of rules, it’s no longer possible to apply that condition and it will be lost. New rules that are inherited from source by default will be shown.

    2. If transport configuration has a persisted condition but related key is found multiple times in the actual list of rules, further identification is possible only if initially object has rules with the same key but different conditions.

    3. If at some moment of time object gets fully duplicated rules (key+condition), for now it will initialize all conditions with the value from the condition of the first rule in the list of duplicated rules.

    One more tricky case occurs when Don’t remove rules that exist only on the target object is enabled in Receivers/Interfaces projection settings. If the option is enabled and conditions are changed for some receivers/interfaces, then:

    1. If target object has already had all receivers and interfaces, target object will contain these receivers and interfaces (with previous conditions) and receivers and interfaces with new conditions after transport.

    2. If target object hasn’t had these receivers and interfaces, target object will contain receivers and interfaces with new conditions after transport.

    Projection can be configured in Receivers/Interfaces projection settings on ICO transport configuration page for PRO binary landscapes:

    receivers interfaces projection settings

    You can keep receiver/interface rules that exist only on target object enabling Don’t remove rules that exist only on the target object.

    You can either exclude or ignore receiver/interface rules:

    • If you exclude specified receiver/interface rules during transport of the ICO, then these rules will be ignored completely and will not be transported.

    • If you ignore specified receiver/interface rules during transport of the ICO, then these rules won’t be excluded but taken from the current target ICO instead. So, specified rules won’t be updated during transport. If the target object doesn’t exist, ignoring isn’t processed.

      If the whole receiver is ignored and target object already has this receiver, extra rules from source object will not be moved to target object.

    On Channel transport configuration page there are a lot of Adapter specific attributes and since of 2112 Figaf Tool supports a possibility to add parameter description with context GUI information that can be taken from adapter metadata payload, filter items by different criteria.

    channel transport configuration page adapter specific attributes

    The following filters are available:

    • 'Changed' filter criteria filters attributes by differences. So all items, all changed items, items having diffs between source and target or items having diffs on target system are shown.

    • 'Non-transportable' filter criteria filters attributes by transportable criteria. So all items, all non-transportable items, all passwords/credentials items or all transportable items are shown.

    Also parameter description with context GUI information can be shown depending on Show parameter description switcher value.

    Parameter description with context GUI information that can be taken from adapter metadata files which location (path to the folder with files) should be set in bootstrap parameter irt.config.pi-adapter-metadata-files. The files should be downloaded from PI system. See Application properties to learn more about bootstrap parameters.

  • CPI Objects:

    You can override transport configuration for older IFlow versions (to enable this feature click on Override for a particular version and select a version).

    It is possible to select draft version only if it’s the latest (it’s impossible to select historical draft versions).

    You can initialize transport configuration by the ancestor values clicking on Init by another object. It opens the dialog where you can select IFlow which IFlow configuration will be used as an ancestor to initialize IFlow external configuration parameters of target object.

    Once transport is created for an object, corresponding transport configuration will be persisted. The following cases are possible:

    • There is no persisted transport configuration for an object and persistence is requested for the latest version, then Figaf Tool will persist new config for the latest version (by group id only).

    • There is no persisted config for an object and persistence is requested for particular version, then Figaf Tool will persist new config for particular version (by group id and tracked object id).

    • There is persisted config for the latest version and persistence is requested for latest version, then Figaf Tool will update persisted config for the latest version.

    • There is persisted config for the latest version and persistence is requested for the particular version

      • if a particular version is not the latest, then Figaf Tool will persist new config for the particular version.

      • if a particular version is the latest, then Figaf Tool will update the persisted latest version as a particular version.

    • There is a config only for a particular version and persistence is requested for the latest version

      • if a particular version is not the latest, then Figaf Tool will persist new config for the latest version (it’s not the real case for normal usage).

      • if a particular version is the latest, then Figaf Tool will update the content of the particular version without changing its type.

    • There is config only for a particular version and persistence is requested for a particular version, then Figaf Tool will update persisted config for the particular version.

    When a configuration is persisted for a concrete transport it’s possible to edit transport configuration for transport items which haven’t been approved yet.

    'Changed' filter criteria filters attributes by differences. So all items, all changed items, items having diffs between source and target or items having diffs on target system are shown.

  • Api Management Objects:

    You can configure Api Proxies (target endpoint properties and URL) and Key Value Maps.

    'Changed' filter criteria filters attributes by differences. So all items or all changed items.

6. Releases page

Releases page shows all existing releases and looks:

releases

On this page you can:

  1. Create new release clicking on New Release button. It opens 'Create release' dialog box where the following properties can be configured:

    1. Title of new release. Should be unique within the organization.

    2. Version of release.

    3. Default Assignee for group ticket creation.

    4. Default Ticket Type for group ticket creation. See Ticket Types for details.

    5. Default Landscape for group ticket creation. The same as Landscape for ticket (see Landscapes).

    6. Default Source Landscape, Default Target Landscape, and Default Migration Landscape for group ticket creation. The same as Source Landscape, Target Landscape, and Migration Landscape for ticket correspondingly (see Landscapes).

  2. Select release(s) and release it(them) clicking on Release button.

    Only releases which all attached tickets are in Migrated, Completed, or Canceled statuses can be released.

  3. View a release details clicking on details button. It opens release page.

  4. Select release(s) and delete it(them) clicking on red trash button.

    The release(s) will be deleted with all attached tickets.

7. Release page

Release 'Title' page provides the features for management and monitoring of ticket groups and looks:

release details page

There are the following operations can be executed on this page:

  1. Opening another release details clicking on open another button and selecting a release.

  2. Expanding the release configuration clicking on details button. It expands the configuration, which can be updated (see release fields here):

    release details with configuration

    If you want to save changes, click on save button. Otherwise, collapse the configuration.

  3. Release the release clicking on Release button.

    Only releases which all attached tickets are in Migrated, Completed, or Canceled statuses can be released.

  4. Changing view perspective:

    view perspective change

    Release has two view perspectives:

    1. Integration scenarios perspective shows scenarios added to tickets attached to the release. Here you can:

      1. Add new scenario clicking on Add Scenarios button (available only if the release hasn’t been released yet). It opens Create new tickets for chosen scenarios dialog box:

        create new tickets for choosen scenarios

        In this dialog box configure properties of new tickets (see almost all of them here):

        1. Ticket creation strategy identifies how objects should be distributed between tickets: One ticket per scenario or All scenarios in one ticket.

        2. Test cases attachment strategy identifies whether test cases should be attached during tickets creation, or not: Attach all available test cases for chosen scenarios or Don’t attach any test cases. If Attach all available test cases for chosen scenarios is selected, ticket’s integration objects lookup and test cases attachment (all found test cases for resolved integration objects) will be processed for each created ticket.

          After configuring new ticket properties click on Add Scenarios. It opens 'Select integration scenarios' dialog box where you can select the objects (submit the dialog box to close it).

          If you have selected unnecessary objects, you can select them and click on Delete Scenarios button.

          Click on Save to create new ticket(s). Selected objects with all dependent objects will be attached to created ticket(s).

          Selected objects should be licensed for DevOps or Migration (see Configure Object Licenses for details).

      2. View integration scenario details clicking on the link of source integration scenario. It opens Integration Object Details page.

      3. View ticket details clicking on scenario tickets and selecting the ticket. It opens ticket page.

    2. Tickets perspective shows attached tickets and provides functionality for ticket management. Here you can:

      1. Attach tickets clicking on Attach Tickets button and selecting the tickets.

        You can attach tickets that are not associated with any release.

        Attach Tickets button is available only if the release hasn’t been released yet.

      2. Detach tickets selecting unnecessary tickets and clicking on Detach Tickets.

        Detach Tickets button is available only if the release hasn’t been released yet.

      3. View ticket details clicking on its id. It opens ticket page.

      4. Monitor ticket stages switching between Prepared, In Development, In Transport, Migrated, and Completed tabs.

        These tabs correspond to ticket stages described here.

      5. Move tickets to next stage depending on previous one:

        1. To development on Prepared tab.

        2. Start transport on In Development tab.

        3. Finish transport on In transport tab.

          To development, Start transport, and Finish transport buttons are available only if the release hasn’t been released yet.

      6. Create Development tickets from selected migration tickets on Migrated tab. It creates development tickets on target system which can be used for moving current development landscape to production.

        Create Development tickets button is available only if the release hasn’t been released yet.

      7. Migrate Transport Configuration of selected migration tickets on Migrated tab. It opens 'Migrate Transport Configurations' dialog box:

        migrate tc

        Where you can configure:

        1. Fill values of parameters inherited from target by static values from source landscape

        2. Migrate passwords if possible (PRO only)

          Migrate Transport Configuration button is available only if the release hasn’t been released yet.