Application Lifetime Management
•
8 likes•6,567 views
The document describes the OutSystems Application Lifetime Management tool called Lifetime. Lifetime provides a centralized management console that gives visibility into all environments on an OutSystems platform. It manages application deployments, users, security, and orchestration across environments. Lifetime analyzes application dependencies and helps users deploy applications by resolving any issues detected. It also provides performance monitoring, custom plugin support, and manages infrastructure security through role-based permissions across all environments.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Application Lifetime Management
Similar to Application Lifetime Management (20)
Recently uploaded
Recently uploaded (20)
Application Lifetime Management
- 1. www.outsystems.com Page 1 © 2015 outsystems – all rights reservedV1.0 Application Lifetime Management
- 2. www.outsystems.com Page 2 © 2015 outsystems – all rights reservedV1.0 The classic OutSystems Platform IDE to develop web and mobile web applications IDE to extend the language and integrate external systems Platform Server Management Console The core of the OutSystems Platform
- 3. www.outsystems.com Page 3 © 2015 outsystems – all rights reservedV1.0 Service Center is the centralized management console of each individual OutSystems Platform environment Service Center
- 4. www.outsystems.com Page 4 © 2015 outsystems – all rights reservedV1.0 How do we orchestrate more than one environment? How can we know what applications are where and in what version? How can we have an overview of what users can and where? But…
- 5. www.outsystems.com Page 5 © 2015 outsystems – all rights reservedV1.0 LifeTime is a unified console with visibility of all the environments on the same OutSystems Platform infrastructure. It manages the deployment of applications, IT users, and security across all environments. Meet LifeTime
- 6. www.outsystems.com Page 6 © 2015 outsystems – all rights reservedV1.0 ▪ Prepare the deployment by tagging the applications and creating a plan complemented with some post-deployment notes ▪ Execute the deployment ▪ Applications have dependencies and this complicates the deployment process ▪ LifeTime determines the impacts of a deployment and helps the users to solve the problems detected Deploying an application - Recap
- 7. www.outsystems.com Page 7 © 2015 outsystems – all rights reservedV1.0 Infrastructure Security Creating Roles Managing IT Users Users & Roles
- 8. www.outsystems.com Page 8 © 2015 outsystems – all rights reservedV1.0 • Manage infrastructure security in a single point • Manage security with Roles Infrastructure Security
- 9. www.outsystems.com Page 9 © 2015 outsystems – all rights reservedV1.0 Creating Roles
- 10. www.outsystems.com Page 10 © 2015 outsystems – all rights reservedV1.0 • A user created in LifeTime – Exists across all environments – Is assigned to a single Role – Can have application- specific permissions Managing IT Users
- 11. www.outsystems.com Page 11 © 2015 outsystems – all rights reservedV1.0 • Role permissions and application-specific permissions Managing IT Users
- 12. www.outsystems.com Page 12 © 2015 outsystems – all rights reservedV1.0 • Simplified security – Managed at infrastructure level – Role Based • Application specific permissions – Managed at environment level – User Based Users & Roles - Recap
- 13. www.outsystems.com Page 13 © 2015 outsystems – all rights reservedV1.0 Preparing an application for Deploy Deploying an application Anatomy of the Deployment Understanding applications dependencies Deploying an application with dependencies Applying a Hotfix Application Deployment
- 14. www.outsystems.com Page 14 © 2015 outsystems – all rights reservedV1.0 • What is the usual process? – Freeze a version of a set of modules and tag them – Create the package (of those modules) – Send it to Operations team with some Installation Notes including: • Deployment steps • Application Configuration Preparing an application for deploy
- 15. www.outsystems.com Page 15 © 2015 outsystems – all rights reservedV1.0 • What is the usual process? – Freeze a version of a set of modules and tag them – Create the package (of those modules) – Send it to Operations team with some Installation Notes including: • Deployment steps • Application Configuration Preparing an application for deploy Application
- 16. www.outsystems.com Page 16 © 2015 outsystems – all rights reservedV1.0 Preparing an application for deploy Tag Version LifeTime suggests the next minor as the new version number by default. It is also possible to select the next major or even a custom version instead
- 17. www.outsystems.com Page 17 © 2015 outsystems – all rights reservedV1.0 Preparing an application for deploy Deployment Plan
- 18. www.outsystems.com Page 18 © 2015 outsystems – all rights reservedV1.0 Extra information for the Operations Team member that will carry out the staged plan, including additional eSpace and environment configuration needed such as • Site Properties • Timers • Web References • Database Connections • SEO Rules Deployment notes What kind of thing will be there?
- 19. www.outsystems.com Page 19 © 2015 outsystems – all rights reservedV1.0 Deploying an application - Roles An Administrator-level user, that works in the Operations team, will execute the deployment plan that a Development team member has created. While the deployment is executing, the Developer can follow it in LifeTime.
- 20. www.outsystems.com Page 20 © 2015 outsystems – all rights reservedV1.0 Deploying an application Deploy screen
- 21. www.outsystems.com Page 21 © 2015 outsystems – all rights reservedV1.0 Deploying an application Following the deployment
- 22. www.outsystems.com Page 22 © 2015 outsystems – all rights reservedV1.0 Anatomy of the deployment What is happening behind the scenes?
- 23. www.outsystems.com Page 23 © 2015 outsystems – all rights reservedV1.0 Dev Environment QA Environment Front-end(s) Anatomy of the deployment Lifetime Deployment Controller Deployment 2. Process impact analysis 3. Compile XML ASPX/JSP DLL/JAR ZIP 4. Analyze DB 1. Retrieve and send modules 5. Distribute to front-ends SQL Script 6b . Deploy in Application Server 6a. Update DB 7 . Sync environment ASPX/JSP DLL/JAR
- 24. www.outsystems.com Page 24 © 2015 outsystems – all rights reservedV1.0 Understanding application dependencies Consumer Module Producer Module Referenc es to objects Sales Mobile Sales Customer Services Deploying a producer may require deploying its consumers
- 25. www.outsystems.com Page 25 © 2015 outsystems – all rights reservedV1.0 Deploying an application with dependencies LifeTime performs impact analysis and takes preventive action every time an application is selected. In this case it is necessary to resolve some dependencies.
- 26. www.outsystems.com Page 26 © 2015 outsystems – all rights reservedV1.0 Deploying with Incompatible Dependencies Application has incompatible references
- 27. www.outsystems.com Page 27 © 2015 outsystems – all rights reservedV1.0 Repairing Incompatible Dependencies Application with errors Drill-down on application Open in Service Studio
- 28. www.outsystems.com Page 28 © 2015 outsystems – all rights reservedV1.0 Applying a Hotfix LifeTime detects a publication in this environment. The hotfix needs to be propagated backwards. The hotfix is deployed to production.
- 29. www.outsystems.com Page 29 © 2015 outsystems – all rights reservedV1.0 ▪ Prepare the deployment by tagging the applications and creating a plan complemented with some post-deployment notes ▪ Execute the deployment ▪ Applications have dependencies and this complicates the deployment process ▪ LifeTime determines the impacts of a deployment and helps the users to solve the problems detected Deploying an application - Recap
- 30. www.outsystems.com Page 30 © 2015 outsystems – all rights reservedV1.0 Performance Monitoring Custom Plugin Support Additional Features
- 31. www.outsystems.com Page 31 © 2015 outsystems – all rights reservedV1.0 • Score • Trends • Page Views • Load Time Performance Monitoring - Metrics
- 32. www.outsystems.com Page 32 © 2015 outsystems – all rights reservedV1.0 • Overall • Application • Module • Screen Performance Monitoring - Scope
- 33. www.outsystems.com Page 33 © 2015 outsystems – all rights reservedV1.0 Custom Plugin Support For Staging and Request info analytics
- 34. www.outsystems.com Page 34 © 2015 outsystems – all rights reservedV1.0 Custom Plugin Support Lifetime SDK
- 35. www.outsystems.com Page 35 © 2015 outsystems – all rights reservedV1.0 Custom Plugin Support Getting data for testing Export Import LifeTime Filtered Data LifeTimeSDK Sample Data
- 36. www.outsystems.com Page 36 © 2015 outsystems – all rights reservedV1.0 The End
Editor's Notes
- The OutSystems Platform is a high productivity development platform that enables companies to create and change web and mobile web enterprise grade applications. Applications are delivered on-time and on-budget, fully integrated with existing systems and built for continuous change. The OutSystems Platform provides all the required tools and functionality to fully support and automate the delivery and maintenance of web business applications. At the core of the OutSystems Platform is the Platform Server, responsible for building and running these applications that are built using a visual IDE, the Service Studio. The OutSystems Platform easily extends and integrates with external systems and services through the Integration Studio tool. The Service Center component is a management console for the OutSystems Platform, allowing you to manage and configure the platform and the
- Service Center is the administrative web console for the OutSystems Platform. It is a web application that interacts with all the components of the Platform Server, providing a web-browser interface for system administrators, managers and operation teams to control every aspect of the OutSystems Platform. Service Studio and Integration Studio also interact with the Platform Server through Service Center, using specific web services for that purpose. Service Center is itself a web application developed with Service Studio. The main sections in Service Center are: Home: The entry point, showing an overview of recent deployment activity, statistics of recent application web hits and user accesses, and the licensing status Factory: Manages the OutSystems Platform factory (eSpaces, Extensions, Solutions and Applications). All factory management is performed in this section: both application deployment and management of applications’ runtime properties Monitoring: Provides access to the OutSystems Platform logging and health status checks. All the troubleshooting of OutSystems Platform and applications misbehaviors starts here Administration: All environment-wide configuration of the OutSystems Platform is done in this section. Licensing tasks are also performed here Analytics: Gives visibility on the usage of your OutSystems Platform environment with a set of automatically-generated analytics; it also allows the creation of reports, based on the OutSystems Platform logging, allowing advanced analysis of platform usage and performance troubleshooting.
- LifeTime is a unified web console that has the complete picture of all the environments of the OutSystems Platform infrastructure. It allows you to manage the cross stage deployment of applications, control versions of these applications, manage hot fixes so that these corrections are not lost and manage permissions for IT users and teams. It is important to clarify some basic terminology before moving forward: An Environment is a (distinct) installation of the OutSystems Platform, that may operate standalone (single-node) or in a web farm (multi-node) configuration. Most factories have several environments, each of which maps to different stages, e.g. Development, QA, Pre-Production and Production environments; An Infrastructure is the complete set of environments (stages), conceptually chained together to support the full life-cycle of the applications; LifeTime allows you to increase the control over your development factory by: Simplifying cross stage deployment: by having automated deployment processes across all your staging environments (Development to Production) you simplify processes and increase overall IT efficiency; Reducing risks in deployment operations: by running impact analysis and ensuring you know the exact impact the deployment of an application has in Production; Increasing reliability: staging processes are automatically verified, eliminating human errors, minimizing deployment risk and empowering IT staff to focus on higher value operations; Allowing you to react fast to critical change requests: always control exactly what is running in Production and easily replicate those versions back into Quality Assurance to fix and test defects with confidence; Simplifying security policies: ensure Developers and Operators have the appropriate privileges in each environment. Simplified cross stage policies give you the necessary control to make sure your application management processes are fast, low risk and efficient.
- LifeTime is a unified web console that has the complete picture of all the environments of the OutSystems Platform infrastructure. It allows you to manage the cross stage deployment of applications, control versions of these applications, manage hot fixes so that these corrections are not lost and manage permissions for IT users and teams. It is important to clarify some basic terminology before moving forward: An Environment is a (distinct) installation of the OutSystems Platform, that may operate standalone (single-node) or in a web farm (multi-node) configuration. Most factories have several environments, each of which maps to different stages, e.g. Development, QA, Pre-Production and Production environments; An Infrastructure is the complete set of environments (stages), conceptually chained together to support the full life-cycle of the applications; LifeTime allows you to increase the control over your development factory by: Simplifying cross stage deployment: by having automated deployment processes across all your staging environments (Development to Production) you simplify processes and increase overall IT efficiency; Reducing risks in deployment operations: by running impact analysis and ensuring you know the exact impact the deployment of an application has in Production; Increasing reliability: staging processes are automatically verified, eliminating human errors, minimizing deployment risk and empowering IT staff to focus on higher value operations; Allowing you to react fast to critical change requests: always control exactly what is running in Production and easily replicate those versions back into Quality Assurance to fix and test defects with confidence; Simplifying security policies: ensure Developers and Operators have the appropriate privileges in each environment. Simplified cross stage policies give you the necessary control to make sure your application management processes are fast, low risk and efficient.
- LifeTime is provided with functionality for managing security, namely through roles for defining typical permissions per environment of your infrastructure. Your infrastructure is the collection of your environments and the applications within. Managing its security will comprise of managing the user’s permissions to the applications across all environments. This can be done in LifeTime using Roles. About Roles Roles are common sets of permissions per environments of your infrastructure. By assigning a role to an IT user, the permissions of that role are inherited by him or her. By default, LifeTime is provided with two roles (though additional roles can be added): Developer: allows deployment of applications in Development environment, opening applications in Quality Assurance, and listing applications in Production; Administrator: allows deployment of applications in all environments of the infrastructure, as well as managing IT users, security, and environments. In this slide’s scenario, there's an infrastructure of 3 environments with an additional role besides the default ones: The Architect role, which allows to deployment of applications in development, and Open & Reuse of applications in Quality Assurance and Production.
- This topic describes how to create a custom role with specific permissions as featured on the last slide. In this example the Architect role is going to be created and assigned to application architecture developers, with the following permissions per environment: Development Environment: permission to Deploy applications; Quality Assurance Environment: permission to Open & Reuse applications; Production Environment: permission to Open & Reuse applications; Upon completion, this new role is assigned to an IT user. Other roles you may want to create on your factories include External Developer, Team Leader, Delivery Manager, etc.
- A user created on LifeTime will exist on all environments, and can have potentially different permissions on each environment, as granted by the mandatory Role assigned to the user. He or she can then have application-specific permissions that fine-tune access to the applications in the infrastructure.
- A user will have Role permissions that are applied to all applications in an environment, with potentially different permissions across each infrastructure environment. As an example, Richard Y. Adams has the following Role based permissions: Development Environment: Open & Reuse Quality Environment: Open & Reuse Production Environment: List Versions In addition, it’s possible to grant application-specific permissions to a user, allowing them to overwrite the Role permissions for that application only. In this example, Richard Y. Adams has the following specific permissions for the Directory application: Development Environment: Change & Deploy Quality Environment: Open & Reuse Production Environment: List Versions Notice that the permission on the Development environment for the Directory application differs from the permissions granted by the Role for that same environment. When this happens the most specific (i.e. the user) privilege prevails, regardless of it being an increase or a restriction in access.
- Why Tag an Application? Tagging an application is critical to ensure infrastructure stability and flexibility. It is usually performed when the application development is stable or a milestone is reached, allowing for retrieving that state of the application and its modules at any time in the future. Development teams normally tag a version of their application each time they reach the end of a sprint. Then, they start a new sprint and continue developing their application. The first time an application is published to Development LifeTime automatically tags it with version 0.1. After each tagging operation, the development team habitually continues their work and publishes changes to the application modules. When this happens, LifeTime will identify these changes by showing a '+' (plus) sign next to the version number to highlight that the application has been changed. Tagging an Application Once a sprint has ended or a stable version of the application is developed, open the Applications screen and click on the application to open the Application Detail screen. Start the tag operation by clicking on the 'Tag Version' button. LifeTime automatically provides suggestions of versions to tag: Minor Version: Use this version while in the life cycle of developing and testing the application. LifeTime suggests an increment to the minor number of the current version while leaving the major number untouched; Major Version: Use this version for major releases of the application, which normally go to production. LifeTime suggests an increment to the major number of the current version and a reset of the minor number; Custom Tag: use this to tag the application with another version from the ones suggested. This should be used when performing a tag based on a previous one, for example creating the 0.7.1 tag based on the 0.7 version. It is also possible to select specific versions of the application modules, but this is an advanced feature that must be used with extreme caution because you may end up with an inconsistent version of the application!
- Let’s see how to improve the integrity of an infrastructure by deploying an application in two steps. In this particular example, there's a new version of the Directory application that is ready to go live. The steps to safely deploy an application are: 1. Creating the plan After reaching a stable new version, the team prepares the deployment plan. In the deployment summary screen, the deployment notes are filled in and the Plan is saved. 2. Executing the plan When the Operations team is ready to deploy the app, they click on the 'Planned' button and confirm the deployment in the next screen. During its execution the team can follow the deployment procedure. Note Although the tag version and plan deployment are show here as separate tasks many times they happen at the same time. For that purpose it is possible to execute them in tandem by using the option Tag & Deploy.
- Melissa logs into LifeTime and validates that there’s a plan to deploy something from Development environment to Quality environment. By pressing the Planned button she gets the full detail of the deployment plan, including which applications will be deployed, what versions of those applications and the post-deployment instructions to be carried on. Melissa executes the plan by pressing the 1-click deploy button and confirming the action.
- The deployment screen shows the progress of the deployment operation. It also shows the content of the “deployment package”, i.e. which applications and what version are being deployed to the destination. The deployment notes that the deployment planner indicated are also accessible in this page. Finally, there’s a comprehensive log of the whole deployment process. This log is very useful when something unexpected occurs in the deployment process and is flagged by LifeTime. Deployment Results In case the deployment is still undergoing, you can see in real time the status of the deployment process. Once the deployment has finished, click on 'View Last Deployment' to view the final state of the applications, as well as a detailed log of the complete deployment process.
- It is also possible for other users, namely the person who Tagged and Planned the deployment, to follow the deployment process as it occurs.
- The anatomy of the deployment, mapped to last slide’s deployment steps: Lifetime starts by 1. Retrieving applications' models from version control After this, the Deployment Controller Service (running on the machine with the Deployment Controller role) moves on to… 2. Analyzing impact on running business processes 3. Generating and compiling optimized ASP.NET C# code 4. Analyzing database and creating differential SQL scripts 5. Distributing compiled applications to front-end servers Then, the Deployment Controller starts 6a. Updating database And after that succeeds, each Front-End machine’s Deployment Service concurrently performs 6b. Hot-deploying new versions Finally, Lifetime completes the deployment by 7. Synchronizing Environment
- Modules can reference elements of other modules. In this relationship one module acts as a producer and the other as a consumer of this reference. This dependency has impact on the publishing process. The OutSystems Platform will need to compile both modules. When these modules belong to different applications this dependency creates also an application dependency, i.e. the application of the consumer module depends on the application of the producer module. The application dependency has impact in the staging process, meaning that both of the applications may need to be deployed to another environment for the system to be consistent. Hence, dependencies must be resolved to avoid inconsistencies and errors.
- Here’s an example of the process of deploying an application with dependencies: 1. Determining Dependencies A new Customer Portal Application will be developed, which will reuse business logic from both the Cases and CRM Services applications. To ensure the stability of all applications, Cases and CRM Services are deployed to Quality Assurance to be tested, even before developing the Customer Portal. 2. Impact Analysis After a development milestone is finished in the Development environment, the Customer Portal application is ready to be deployed to Quality Assurance for testing. LifeTime's impact analysis detects that Customer Portal depends on two other applications (Cases and CRM Services) and it is not yet possible to deploy it: the option becomes red and the deploy button changes to red too. 3. Understanding the problem To help you understanding what is happening, LifeTime provides information obtained from the impact analysis, so that you can make an informed decision on which action to take in order to proceed with the deployment to Quality Assurance. 4. Resolving Dependencies In the list of applications, let's set the deployment option for the CRM Services to deploy the latest version to Quality Assurance. In each selection of a deployment option, the impact analysis is executed. Since the Cases also depends on the CRM Services, it must be updated in Quality Assurance to use the newer version of CRM Services (that is being pushed forward). Therefore, LifeTime automatically changes the deployment option of the Cases to 'Redeploy 1.0'. 5. Deploying Once all dependencies are resolved, you can proceed with the deployment normally.
- In LifeTime, you may eventually find applications flagged with a red cross icon next to them in an environment. This means that they are currently using (referencing) functionality of other application(s), but that functionality is no longer available or is incompatible. These flagged applications are said to have incompatible references. In the example above the Sales application has (one or more) incompatible references in the Quality Assurance environment. Further investigation would reveal that Sales is using a public action of Customer Services, that has a new mandatory input parameter in Quality Assurance while the running version of Sales on that environment is still bound to the old action prototype. An application with incompatible references can be run, but you will probably experience runtime errors or misbehaviors while using it. The 'Leave Incompatible' Deployment Option When you click the 'Deploy...' button and open the screen to select applications to deploy, LifeTime automatically sets all applications with incompatible references to the 'Leave Incompatible' deployment option, which leaves it out of the impact analysis performed by LifeTime. In the example above, until you actually push forward Sales 2.4 (that fixes the reference to Customer Services), LifeTime is unable to fix Sales in QA. Because of this and to minimize roadblocks to publishing other applications (like TimeSheets), LifeTime gives you the option to 'Leave Incompatible‘ until such time where you are ready to tackle Sales. Deploying to an Environment with Incompatible References When selecting an application to deploy to an environment that currently has incompatible references, it is always important to validate whether the application you are deploying depends on any of those application with incompatible references. You therefore have two possible scenarios: If the deployed application depends on applications with incompatible references: Check the following slide ‘Repair Deployed Applications’; If the deployed application has no dependencies to incompatible references: Check the earlier slide ‘Deploy An Application’;
- These are the steps to repairing applications that were left with incompatible dependencies (by the publication of a new version of one of its producers, that contains changes to the interface between them): 1. Understanding the Problem LifeTime displays a red icon near every application that is not running properly, so that you can easily understand at a glance the status of all applications running on each environment. In the example above, to find out what the problem with Mobile Sales is, click ‘Mobile Sales’ (on the Applications tab) to display the details of the application. On that screen, hovering the mouse over the error icon next to the MobileSales module, will show a tooltip with the description of the problem: the module has broken references. To know which references are broken, the Mobile Sales module has to be opened and analyzed in Service Studio. Use the link in LifeTime to do that. You will find that the problem is in the reference to the Sales eSpace. 2. Solving the Conflict Back in LifeTime, you notice that there's a new version of Sales in Development which is free from incompatibility errors: this means that reference problems are solved there. We should therefore deploy Sales 2.0 to Quality Assurance. When the deployment finishes, Mobile Sales 2.0 will have no more conflicts. It will now references Sales 2.0, making the Quality Assurance environment run without errors.
- This topic describes how implement an immediate corrective development, also known as a Hotfix. 1. Fixing the Defect In the present example, a severe defect was discovered in the Documents application in Production and has to be immediately fixed. The version number in Pre-Production has changed: it is suffixed with a '+' (for new changes) and is in red because it is a hotfix. 2. Deploying the Hotfix to Production To apply the hotfix to Production, simply deploy the application from Pre-Production to Production as you would do normally: LifeTime automatically suggests you to choose 'Tag & Deploy 1.7.1', that is, LifeTime automatically tags the hotfix changes with a third number in Pre-Production and deploys it to Production. Both Pre-Production and Production now have the 1.7.1 version, but the Pre-Production version will still be displayed in red as the hotfix needs to be propagated backwards. 3. Propagating the Hotfix To solve a hotfix, all changes made to the application have to be propagated backwards to all of the previous environments; in this case first to Quality Assurance, and then to Development: Click on the Documents application: the modules are listed and the ones with the hotfix are marked with a red '+'; Merge all the modules containing the hotfix changes in Pre-Production to Quality Assurance: click on the compare button (the difference sign) between the environments and select the specific changes you have done to implement the hotfix; In Service Studio select the hotfix changes and click 'Merge'; In Service Studio publish the new versions of the modules to Quality Assurance; Repeat steps 2, 3 and 4 from Quality Assurance to Development. When the fix is propagated through all environments, click the 'Mark Hotfix as Solved' button on the application details screen, to signal that the fix is now implemented across all environments in the infrastructure. The hotfix is now solved and there should be no more application versions marked in red.
- A common difficulty in tracking down performance problems reported by the application end-users, is that the server side performance metrics don’t always reveal the application performance as seen by the user. With that in mind, OutSystems Platform 8 introduced a new metrics tool that collects client-side performance information of all applications, providing a more accurate reading of the application’s perceived performance. The Performance Monitoring tool is available directly on LifeTime under the Performance section, and provides the following performance metrics: Performance score Performance trends Page views Client-side page load times All these metrics are available for any time frame, from daily, to weekly, monthly and yearly, or a custom time period. These metrics are based on the APDEx standard. More Information available at http://www.outsystems.com/help/lifetime/8.0/User_Stories/Monitor_the_performance_of_applications.htm http://apdex.org/
- Accessing the Performance Monitoring will immediately redirect the LifeTime user to a global performance Dashboard, providing immediate performance information of all applications. It’s possible to drill down the analysis scope and get performance metrics for each application, each module and each screen of the application. You can sort applications by page views, performance score or load time. The Performance Monitoring tool will automatically highlight the least performant application/module/screen for easily identify the performance problems on the applications. More Information available at http://www.outsystems.com/help/lifetime/8.0/User_Stories/Monitor_the_performance_of_applications.htm
- A plugin is just an application with an entrypoint in the LifeTime menu bar "More" dropdown. Plugins are registered by an eSpace, and only one per eSpace, and uses LifeTime SDK. Sample at: http://www.outsystems.com/forge/component/405/geo-performance/
- LifeTimeSDK is simply application that can be installed in an environment. Includes LifeTimeSDK.oml & LifeTimeCore.oml When LifeTimeSDK is installed in an environment, a new button appears in Service Studio to create LifeTime plugins See also: http://www.outsystems.com/forums/discussion/10329/introducing-the-outsystems-platform-8-0-apis/ http://www.outsystems.com/forums/discussion/10247/how-to-create-a-lifetime-plugin/
- Sample (real) Data can be exported from the LifeTime environment to the target environment the information of applications' versions of at least 2 months Each LifeTime entity has its own .xls file, all .xls files are packed into a .zip file. LifeTimeMonitoring RequestData is packed into a different .zip file Both .zip files are sent to the target environment Import is protected LifeTime cannot be installed user must have change/deploy permission