At this point, you will want to review the WebParts and Process that we have created so far.
- Training: WebPart A
- Training: WebPart B
- Training: WebPart A
- Training: WebPart B
We have created two WebParts, one stand-alone Process, and two WebPages. Take a moment to look through these and remember all the features used to create them.
Training: WebPart A
Training: WebPart B
WebPart Toolbox Tools
WebPart Canvas Properties Used
- Text (Static/Dynamic)
- Text (Dynamic)
Training: WebPart A
Training: WebPart B
Training: Send an Email
Testing and Error Handling
Now you’re almost done! One of the most important parts of development is the testing and cleanup step. Whenever you are developing a feature, you build it for one use case: everything works as expected. After you finish development for that case, it is important to take a step back and review what you have built. Every feature has multiple cases. You now need to ask “what could go wrong?” and add it some error handling for those cases.
Use your WebParts and Processes in a browser and try to break the features you have made. When you find an action that causes your WebPart/Process/WebPage to act unexpectedly, ask “how should it act in this case?”. This will help you design your error handling for your feature.
Think about how your feature will be used in a production environment. So far the little tests you have done along the way have been from the point of view of the developer. You will now need to act as a user and use the feature as intended. It may also be helpful to get input from someone else. It can sometimes be beneficial if the person testing a feature is not also the person who developed it.
Another approach is to try teaching someone else how to use your feature. Even if you do not have anyone to teach, practice how you would teach someone to use your feature. This might help you take a step back and approach it as you would as a user instead of a developer.
Create a table of all possible uses. This may help you better visualize all the different uses for your feature. For this simple training example, it might be easy to just think through all the cases and test them without creating a table, but it is good to get in the habit of doing this. As the features you build become more complex, this will help you think through all possible scenarios and even share your table with others afterwards to get feedback on more scenarios you did not think of.
As you test each case, mark it as either successful and move onto the next case, or troubleshoot the issue (using logs) to fix it. After you make any changes, you will have to retest all the previous cases you already marked as successful.
A sample table is below and accounts for some of the possible scenarios. Create your own table and try to think of more cases to add before beginning your test.
WebPart B Use Case
User load the page for the first time
User filters the list section by Address Number
User filters the list section by Name
User filters the list section by Address Number and Name
User enters nothing in the filter textboxes and clicks the Search button
User checks no checkboxes and clicks the email button
User checks one checkbox and clicks the email button
User checks multiple checkboxes and clicks the email button
User uses the “Select All” checkbox in the header row to select all and clicks the email button
A list of some error cases you may encounter is listed below, but before looking at the list, try to find them yourself. If you can review your feature and cannot find any more ways to break it and have added all the error handling you think is necessary, review the list.
After testing is complete, you are ready to clean up your Processes and Webparts. Clean up is an important step because you may remember everything now, but in the future you may need to relearn how your feature works and messy canvases make that learning process harder.
- Straight Lines/Lined Up Services: During development, you may not have maintained straight lines in your process and after working on it for some time, the arrows and services may be a bit messy. Try to work from the start, down in a single column, until the column gets to be too long, then wrap back up to the top. In this way, processes can get to be very large before you cannot see it fully on the screen.
After Clean Up
- Delete Floating Services: During development, you may have dragged services onto the process canvas that you didn’t end up using. Now is a good time to go through them and delete the ones you no longer need. If you do still want to keep services that are not connected, you can organize them off to the side so it is obvious that you intentionally kept them. If you want to provide some notes for a future developer, you could create an evaluate and write some notes about what you changed, why you changed it, how the logic works, and why you saved the floating services.
After Clean Up
- Connect To Terminate: After the testing step, your processes may no longer be one straight path. You may now have binary decisions to handle your error cases. Remember to connect all of your process ends to a “Terminate” service. You can have multiple “Terminate” services on a process canvas.
After Clean Up
- Name your Services: Ideally, you have named your services along the way to be meaningful to you and the logic you are performing. However, if you haven’t yet, it is best to do this now while you still know how everything works. This is because other services that reference it by name also need to update the reference once the name changes. As you work on other features created by other developers, you will appreciate the names because it is difficult to tell what is happening without it.
After Clean Up
- Create a “Prevalues” Evaluate: It is a good idea to create an “Evaluate” at the beginning of your process to store variables that you will be referencing in your process. You can name this anything you like, but “Prevalues” is a suggestion.This is useful in case you want to change the change the name of the label you are pulling from the page. If you do this, you will need to change the reference in the process. If you have an evaluate at the beginning that is actually pulling the value from the page, you will just have to change it here and the rest of the process is actually referencing WorkData/Prevalues/LabelName.
Prevalues on Process Canvas
Prevalues Evaluate Configuration
- Delete (Or rename) Test Processes: During development, you may have copied processes as backups or created test processes. This might be something you encounter when making complex changes that require a lot of user input to create a scenario you are testing. Rather than recreate that through the website each time, you might have created a process to set up that scenario and then start the logic you are testing. After your logic is incorporated into the site as intended, this test process will still exist, but will never be needed again. Future developers may not know if it can be deleted or not and will leave it just in case. This is especially true if you copied an existing process, because the name will be something meaningful and appear like it is used somewhere on the site. As part of clean up, remember to either delete these processes or rename them to “Do Not Use” or “Test [Developer Name]” so you can use this as your test process again in the future.
- Name Sections: Naming sections is usually just more visually pleasing for future developers. They are all referenced by an Id from process canvases, so if the section is not set to display the header on the page, then it will only show on the WebPart canvas. Still, as WebParts you work on become more complex, all the “New Section” descriptions will be hard to navigate or direct others to various areas in your WebPart.
- Field Names: Field names are referenced from processes, so hopefully at this point you have chosen clean, meaningful names for your fields. If you copied them during development, since names must be distinct, it would have added a number to the existing name in order to create a copy. Make sure these are no longer needed. Remember which fields you have referenced from within a process because the reference will need to change as well. This is why it is a good idea in your processes to create an “Evaluate” at the beginning to store the values you are going to be using during your process (values from the page).
After Clean Up
- Delete (Or rename) Test WebParts: During development, you may have copied WebParts as backups or created test WebParts. After all the WebParts that will be used in the feature are integrated into the site (referenced in WebPages/hyperlinks), find all the WebParts that are not used and either delete them or rename them to “Do Not Use” or “Test [Developer Name]” so you can use them as your test WebPart again in the future. If you do not do this, future developers may not know if it can be deleted or not and will leave it just in case. This is especially true if you copied an existing WebPart, because the name will be something meaningful and appear like it is used somewhere on the site.
- Delete Test Files: We haven’t done anything with files yet, but when you begin working with file saving, downloading, moving, etc, you will be creating many test files. These will remain on the server you are working on until someone deletes it, so it is best to delete the files while you still remember which ones are not needed.
- Delete Test Directories: We also have created any directories, but just like files, you when you start working with these, you will create many test folders. In the future, other developers will be wary of deleting folders because if a process requires it to be there, it will not work once it is deleted. In order to not risk this, developers will rather leave the folder where it is even though it appears to not be used. After you have finished working on your feature, clean up any folders you have created.
With the testing, you have had a chance to take a step back and look at your feature from the point of view of a user. You also cleaned up your work, but that may not be enough to decipher what your logic is doing. Now, you need to put yourself in the place of your future self and other future developers who do not know how your feature works. Are the cleaned up Processes and WebParts enough to help someone walk through your logic? If not, can you clean up your feature more by adding more helpful names to your services? If you feel future developers will still need help, you can add some documentation. Below are some suggestions to add documentation to Processes and WebParts.
- Backup Evaluate: If you want to take a backup of some services that you don’t want to delete, but are not used in the process flow, you can set them off the side in your process canvas underneath an “Evaluate” service with the name backup. The name of the service cannot have spaces or special characters in it, but you can distinguish the backup by putting the date after it with numbers and periods to separate the month, day, and year. Inside the backup, you can create an eval also named backup and put any comments you like inside. A good idea is to put your name as the developer and list out the changes made, issues you encountered, or walk through the logic of how and why it works.
Backup Evaluate on Process Canvas
Backup Evaluate Example
- README Evaluate: If you want your documentation to draw more attention, you could create an “Evaluate” service, name it “README”, and place it at the beginning of the process instead of off to the side.
README Evaluate on Process Canvas
README Evaluate Example
- XSLT Comments: Within Services, anywhere you can type text, you can place an XSLT comment. EASYProcess will change the color of XSLT comments to green to help you distinguish comments from the text that will be used by EASYProcess. XSLT comments are ignored by EASYProcess
- Encase your comment like so: <!-- Comment Text -->
Prevalues Evaluate with XSLT Comments
- HTML Generic Control with HTML Comments: An HTML Generic control allows you to type a lot of text into a web control by typing in the “InnerHTML” property. Be careful, because this will appear on the page unless you configure it correctly. Set your html generic control “Active” property to “False”. You can also set the section it is in to also have the “Active” property set to “False”. You can mark your comment as an HTML comment in case it ever were marked as active again, it still wouldn’t show on the page because it is commented out.
- Encase your comment like so: <!-- Comment Text -->
README HTMLGenericControl on WebPart Canvas
README HTMLGenericControl Example
After taking some time to try and find the error cases for your built WebParts, Processes, and WebPages, you can review this list below and see how many you found on your own.
The Stand Alone Process Fails
This is one error case which was covered in a previous chapter. If the process fails, you return a message to the user informing them the email to send the date/time could not be sent. You have access to the process call’s Output message. If you wanted, you could include this in the message you display to the user.
An email might fail because the SMTP server is busy, the email address does not exist, or the smtp server credentials are wrong. Each of these reasons might make you want to design the error handling differently.
In our example, the email is not important, but in a production environment, the email failing could result in undesirable consequences. A feature could be built to maintain an error queue of the failed emails for your feature. If the email is just simple text, you could save all the fields from the email in a database. You could also create a page which queries this ErrorQueue table in the Application database and displays them in a list section. An admin for the site could periodically review this error queue and a button process could be made to resubmit the email.
The F0101 Record Does Not Have a F0116 Record
In the WebPart B Data Source, we are joining F0101 with F0116 using an Inner Join. This means that we are selecting the intersection of these two tables. If a record from F0101 does not exist in F0116, it will not be included in the results of the query. Think about if this is something that we want to happen.
If we wanted to return the records from F0101 anyway, we could change the join to a Left Join, however the columns displaying information from the F0116 table would empty. Since we are ordering on a date column from the F0116 table, how might this affect our ordering of the query results?
If you wanted to still display the results from F0101 even if it did not exist in F0116, you could perform a Value Transformation so the date column of that record reads “N/A” instead of an empty value.
The Data in F0116 Does Not Use the Effective Date Column
After you finish your Data Source you may have noticed that your data does not display anything in this column. If it is not used it, since it is an Int datatype, it would have “0” instead of a meaningful JDE date. You could resolve this by displaying a different Date column instead. You could also remove this column and order the data by a different column. What order is meaningful to the data?
The User Did Not Enter an Email Address
If the user did not enter an email address, the SendEmail service would fail because it would have an empty “To” field. You can check for this in the button process by adding a Binary Decision after the Prevalues Evaluate to check if the email is equal to blank. If it is blank you could display a message to the user displaying what went wrong and how to fix the issue (the email was blank, enter an email address in the text box).
You could use the “ValidationExpression” property of the text box to use regular expression to validation the email format. This would ensure the email is not blank and also always meet a particular format. This would protect against a user typing int “123” and clicking the button, which might not be caught by other error handling.
You could combine this with a Validator. Instead of having red text display next to the text box when the user does not meet the requirements, you could use a Validator (Web Control in the Toolbox) to show a popup which displays the message when the user clicks the button.
After the User Clicks the Email Button, the Rows should Uncheck
If you notice, after the click the button, the rows you selected are still checked. You could correct this by forwarding the page you are on. You could also target the selected rows or the list section itself and set the rows to be unchecked. You could also target the rows as you are processing them in the for each loop. After the email is sent, target that row and change it to be unchecked.
Did you want the user to remain on this page after the emails are sent? In this example it makes sense, but some features may require an action (like sending an email) followed by a forward to another page.
The Email of Selected Rows Fails
If one email fails, do you expect all of them to fail? If you expected all the emails to fail, you could use an “ExitForEach” service to break from the for each since you don’t intend to finish it. You could then display a message to the user.
One email might fail because the SMTP server is busy at that time, but when it attempts the next email, it may succeed. This is a reason you may want to continue the for each loop and attempt to send them all.
In the for each loop you could add a Binary Decision after the SendEmail service that asks “did that email fail?”. If it failed you could direct to an Evaluate service which stores information about that record that was not emailed (ABAN8, ABALPH) so you could tell the user which ones weren’t sent. You could also store information about what specifically failed. Maybe the reason isn’t the same for all the emails that failed. This way you could tell the user the reason each email failed.
In this feature all the emails are going to the same person, but consider a feature where each record is sent to a different user. Perhaps the feature is sending an email to the email on file for that account. If the email is out of date, it may fail for one account, but succeed for another.
You Can Access the WebPage Without Being Logged In
If you have the url of your webpage, you can access it without logging in. Your WebPart could contain sensitive information and it would be bad if an unauthenticated user could access that data. To fix this, open the WebPage and set the security level to 1. Now a user that is not logged in will not be able to access that page.
When creating WebPages, think about what sort of users will be accessing it. Is this a WebPage that should be available to guest users even if it isn’t in the menu?