Understanding the Assessment Summary
Understanding the assessment and what come next
Last updated
Understanding the assessment and what come next
Last updated
When an assessment is run, an initial report and summary is shown to the user in the application. Let's review that now. This is called the assessment summary report. View the report by clicking on View Results after running the assessment:
This will take you to the assessment report. However, note that all the information shown here comes from the inventory files generated in the Output Reports folder when the SMA is run. This is simply a summary of that information. For a more in depth summary, open the Detailed Report document in the output directory.
Each section of the Assessment Results viewable in the application is detailed below.
When you enter the summary it will look something like this:
At the top right of the report, you will find a drop down menu with the date of your execution displayed. If you have run the accelerator multiple times while the same project is open, you will see multiple options in the dropdown menu. The options you see are executions from the project you have open.
At the top left of the report, you will find a link that will help you to understand how to read through the different readiness scores. Below this, there is a detailed explanation of each readiness score.
This includes includes several items, but the key metric is the Readiness Score.
Let's take a look at each section:
Readiness Score - Before we get too far, let’s define what this Readiness Score is and how it is calculated. This is the Spark API Readiness Score. It is the primary indicator of readiness that the Snowpark Migration Accelerator produces. However, this readiness is based only on references to the Spark API, not on any other factors or third-party libraries that may be present in the codebase. As a result, this readiness score can be misleading. There are other factors that you will want to take into account including the presence of third-party libraries. The readiness score should be used as a starting point. The Readiness Score is simply a measure of how many references to the Spark API can be converted to the Snowpark API divided by the total number of references to the Spark API. Both of these values are present in the Spark API Summary section (3541 / 3746 in this example). The higher this value, the better prepared the workload is to work with the Snowpark API. However, recall that this does not take into account any third-party libraries. Note that the Readiness Score can also be found on the first page of the detailed report generated by the tool.
Suggestion on what to do next - Depending on the readiness score obtained, the SMA will advise you on what actions you should take before proceeding to the next step.
Explanation of the Readiness Score - An explanation of what the Spark API Readiness score is and how to interpret it.
Readiness Score Breakdown - A detailed explanation of how the Spark API Readiness Score was calculated. In this case, it will show you the number of usages ready for conversion divided by the number of identified usages. The usages ready for conversion is the count of references to the Spark API that can be converted to the Snowpark API while the identified usages is the count of references to the Spark API that were found in a workload. A reference is any function, element, or import statement that refers to the Spark API.
The Third-Party Libraries Readiness Score will look something like this:
Readiness Score - It will show you the readiness score you obtained and how it is categorized (green, yellow or red score). The Third-Party Libraries Readiness Score represents the percentage of imported libraries that are categorized as supported in Snowflake. You can learn more about this score in the Third-Party API Readiness Score section.
Suggestion on what to do next - Depending on the readiness score obtained, the SMA will advise you on what actions you should take before proceeding to the next step.
Explanation of the Readiness Score - An explanation of what the Third-Party Libraries Readiness score is and how to interpret it.
Readiness Score Breakdown - A detailed explanation of how the Third-Party Libraries Readiness Score was calculated. In this case, it will show you the number of library calls supported in Snowpark divided by the number of identified library calls. The library calls supported in Snowpark refers to all those libraries that Snowpark has support while the identified library calls refers to the total number of third-party library calls identified, including all Spark and Non-spark libraries, as well as the supported and not supported ones.
The SQL Readiness Score will look something like this:
Readiness Score - It will show you the readiness score you obtained and how it is categorized (green, yellow or red score). The SQL Readiness Score measures how many of the identified SQL elements present in a codebase can be converted to Snowflake SQL. You can learn more about this score in the SQL Readiness Score section.
Suggestion on what to do next - Depending on the readiness score obtained, the SMA will advise you on what actions you should take before proceeding to the next step.
Explanation of the Readiness Score - An explanation of what the SQL Readiness score is and how to interpret it.
Readiness Score Breakdown - A detailed explanation of how the SQL Readiness Score was calculated. In this case, it will show you the number of total supported elements divided by the number of total elements.
The issues summary is essential for understanding the conversion issues if you move from the assessment to the conversion phase. The issue output shows the EWI's (Errors, Warnings, and Issues) from the scanned codebase. These issues are gone over in detail in the Issue Analysis section of the documentation.
In the top part of the issue summary, there is a table that sums the different issues that are present.
There are two rows in this table:
Number of issues is the total count of issue codes present in each category.
Number of unique issues is the unique error codes present in each category.
The issues are broken up into three categories:
Warnings are issues that do not necessarily need any resolution, but should be kept in mind as you move into testing the output code. This is usually something that may be slightly different in some edge cases because the source and the target. It could also be a message to let you know that something has changed and looks different to what you would have seen in the source platform.
Conversion issues are elements that did not convert or that require additional input to run in the target platform.
Parsing issues are code elements that the tool was not able to interpret (it could not parse the code). These issues are critical and should be resolved immediately. In most cases, they represent code that does not compile in the source platform or that is otherwise incorrect because of the way it was extracted. In some cases, this could be a grammar pattern that the SMA does not yet recognize. If you think the source code is syntactically correct but are still receiving a parsing error, you should report an issue in the application. Be sure to include the section of source code that is not being parsed.
The counts of each of these are summarized in the table.
Below this table, is a list of each unique issue code.
This give you the Issue Code, a description of the code, the count of how many times that code occurred, and the severity level (based on the Warning, Conversion Error, or Parsing Error categories shown above). Each issue code is hyperlinked to a page in this documentation that describes the code, provides an example, and gives a suggested resolution. (For example, clicking on the the top code shown in the image above in the application will take you to this page on issue code SPRKPY1002.)
Only the top 5 issues are shown by default, but you can expand the list to include the all issue by choosing the SHOW ALL ISSUES button below the table. You can also search for specific issue by using the search bar above the table.
These issues are most helpful in conversion, but in assessment mode, it is still critical to understand the conversion work that remains to be done in any execution. As with all of these reports, you can find the full list of every issue along with it's location in the issue inventory that is created in the Reports folder.
The execution summary has details on the tool execution that was just done. It has the code analyzed score, the user information, the execution id for this particular execution, the version numbers for the SMA and the Snowpark API, as well as the folder information that the user input in the tool in the Project Creation screen.
The appendixes have additional reference information that might be relevant to understanding the output of the SMA tool.
This information may change over time, but it will always be reference information generic to using the SMA as opposed to information specific to the scanned codebase.
This is what the majority of users will see when the run the SMA. If you are user an older version, it's possible you would see the Abbreviated Assessment Summary. This is shown below.
Retry Assessment - After you execute an assessment, on the Assessment Results page you can select the Retry Assessment button to run the assessment again. After examining the output, it is not uncommon to make some changes in the source code and run the assessment again.
View Log Folder: This will take you to the log folder. This folder is created when you run the assessment and a complete set of logs made up of several text files that describe the status of the execution will be deposited here. You can view the logs in any text editor. The logs will be most valuable when it's necessary to troubleshoot through an execution that failed. If there was a failure, the tool may ask you to send the logs. The logs in this folder is what will be sent.
View Reports: This will take you to the reports folder. Like the logs folder, this one is created when you run the assessment. The reports folder contains the output of the assessment including the detailed report, spark reference inventory, and other inventories built from the source codebase. Each report is detailed in this documentation.
Continue to Conversion: Conversion may seem like the logical next step, but before you move on to conversion, make sure you've reviewed the assessment output. To run a conversion, you will need an access code. You can learn more about this in the conversion section of this documentation.
The output reporting generated each time the tool executes will be detailed on the next few pages.
There are some additional options available in the application as well.
