This documentation is no longer maintained and may contain obsolete information. You should instead refer to Application onboarding.
Gather information about the application's technological composition and structure. For example, for a typical JEE application (for example) you should determine:
- The JDK version used to compile the source code
- The frameworks used and the version numbers
- The different application layers
- The archives (third-party)
- The application server used to run the application
This information will support the "out of the box" analysis check and will help ensure that during the source code delivery validation you have access to all relevant application components. In the case of a J2EE application, this means ensuring the App Team has delivered, for example:
- All the Java/JSP application source code, the relevant XML and .properties files and all the client files (HTML, JavaScript ...).
- The deployment descriptor files required for EJB and Web Services analyses
- The archives of libraries required to run the application, including those of the application server
As an example, in the case of a JEE application, many of the standard configurations such as Java version, use of standard framework etc. are automatically discovered by the CAST Delivery Manager Tool by parsing the project file and are included in the delivery package. These and other options can be overridden or manually configured by the CAST AI Administrator based on the information gathered in these forms or discovered by inspecting the delivered source code.
As such, the more thorough and complete the qualification step is, the less effort is required from the CAST AI Administrator to discover the correct analysis settings on his/her own by examining the delivered source code.
Recommended approach...
The recommended approach for executing this, would be to forward the forms Technical Surveys to application team stakeholders for completion and follow-up with a potential meeting with all key application team stakeholders. The objectives of this meeting would include:
- Review any information provided (accuracy, clarity, completeness, etc.) by the application team before the meeting
- Document in the form any relevant missing information
The technical review may include the discovery of the analysis purpose. Understanding the Application team's intended use of the analysis results can help guide and direct the CAST AI Administrator in deciding whether "a good configuration is good enough". This may be the case for example when fine tuning transaction identification: depending on the specific analysis use case, it may be sufficient to identify perhaps less than 70% of the expected transactions where in other cases a more precise tune up of the configuration would be needed. Thus, an understanding of the analysis purpose could help optimize the analysis value vs. effort ratio.
Why is it important?
The information collected is used to:
- Evaluate completeness of the delivered source code
- Assess if an analysis with "out-of-the-box" support is possible and/or determine any potential solutions to address any limitations/constraints
Technology specific information
Please see the following pages for more information specific to each technology:
- C and Cpp - Application qualification specifics
- JEE - Application qualification specifics
- Mainframe - Application qualification specifics
- SAP ABAP - Application qualification specifics
Application architecture review
The Application architecture review aims to develop a high level understanding of the application architecture to help with the configuration of the analysis and the discovery of transactions. This meeting could include the Application Architect, Senior developer, etc. as appropriate.
Why is it important?
The information collected here is used to:
- Evaluate completeness of the delivered source code
- Ensure a complete and accurate analysis configuration
- Support the configuration of transactions
- Support Automated FP calculations