Details

      Description

      Implement logic for detecting offline and upgraded peers, render result in List Applications page (synchronous/background/ajax?)

        Activity

        Hide
        Erik van Zijst added a comment - - edited

        It's necessary to know whether a peer is online or offline, so we can prompt the user with the appropriate actions ("relocate server", "upgrade server"). This is not something we can do in APL in an application-independent way (some apps may not serve anything on their baseUrl, may have a proxy-server / load balancer / etc that still respond even though the app itself is offline, or a non-apl app may not be accessible at all).

        We should therefore add a getStatus() method to the SPI for app types to implement.

        The contract for detecting upgraded peers then becomes:

        if (peer is OFFLINE)
        {
          display "server offline" and "relocate" icon. "relocate" starts Relocate Wizard
        }
        else if (ServerID has changed)
        {
          if (peer UAL.version >= 3)
          {
            peer must be upgraded -> start full Upgrade Wizard
          }
          else
          {
            peer must have downgraded from UAL to non-UAL -> start ServerID Change Wizard
          }
        }
        
        Show
        Erik van Zijst added a comment - - edited It's necessary to know whether a peer is online or offline, so we can prompt the user with the appropriate actions ("relocate server", "upgrade server"). This is not something we can do in APL in an application-independent way (some apps may not serve anything on their baseUrl, may have a proxy-server / load balancer / etc that still respond even though the app itself is offline, or a non-apl app may not be accessible at all). We should therefore add a getStatus() method to the SPI for app types to implement. The contract for detecting upgraded peers then becomes: if (peer is OFFLINE) { display "server offline" and "relocate" icon. "relocate" starts Relocate Wizard } else if (ServerID has changed) { if (peer UAL.version >= 3) { peer must be upgraded -> start full Upgrade Wizard } else { peer must have downgraded from UAL to non-UAL -> start ServerID Change Wizard } }
        Hide
        Tim Pettersen added a comment -

        Nice, looks good to me.

        Show
        Tim Pettersen added a comment - Nice, looks good to me.
        Show
        Erik van Zijst added a comment - https://extranet.atlassian.com/display/~evzijst/AppLinks+Upgrade+Application+Link+workflow
        Hide
        Felix Schmitz added a comment -

        For the following scenario: When relocating an application that is NON-UAL this can then lead to a server id change and this can then mean after doing the "relocation" (changing the url i assume), it will lead to a server id change which then will trigger this server id change wizard. I think from a user perspective it would be good if this is not a second wizard, just one transaction.

        Show
        Felix Schmitz added a comment - For the following scenario: When relocating an application that is NON-UAL this can then lead to a server id change and this can then mean after doing the "relocation" (changing the url i assume), it will lead to a server id change which then will trigger this server id change wizard. I think from a user perspective it would be good if this is not a second wizard, just one transaction.
        Hide
        Erik van Zijst added a comment -

        I think from a user perspective it would be good if this is not a second wizard, just one transaction.

        Yes, agreed. We should attach the upgrade wizard to the relocation wizard.
        I'll mock out those scenarios.

        Show
        Erik van Zijst added a comment - I think from a user perspective it would be good if this is not a second wizard, just one transaction. Yes, agreed. We should attach the upgrade wizard to the relocation wizard. I'll mock out those scenarios.

          People

          • Assignee:
            Erik van Zijst
            Reporter:
            Erik van Zijst
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 6 hours
              6h
              Remaining:
              Remaining Estimate - 6 hours
              6h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Who's Looking?