Connecting the Pieces
By now you should be becoming more and more familiar with EASYProcess. We have created one of each of the most used entities in EASYProcess: WebPart, Process, WebPage. We have created two WebParts and a stand alone Process. We also have created one WebPage to house our WebPart B. However, as a user browsing the site, once you log in, you can only access WebPart B. Just because a WebPage is not accessible from the Menu, doesn’t mean the user cannot access it on the site.
Next, we want to set up a hyperlink on WebPart B so that it forwards the user to a new WebPage with WebPart A on it. On WebPart A, we are going to add a button to call our stand-alone Process.
For the following steps, remember that most of the things we are doing, have already been covered. If you run into trouble try to remember where you did something similar and look at that WebPart/Process/WebPage and if needed, return to that chapter in the training.
Create a WebPage for WebPart A
Create a WebPage just as you did before, but name it so that is references WebPartA.
Description: Training: WebPart A
Go back to the previous chapter where we created the page for WebPart B if you need help remembering. Remember that we are only creating the WebPart, but not adding it to the Entity Hierarchy to place it in the Menu.
Create a Hyperlink in WebPart B
Create a new section and place it at the top of the WebPart canvas. Drag a Hyperlink into the section. Remember to name the Section and Hyperlink something meaningful to you even if the names are not going to be referenced.
We are going to configure our Hyperlink by looking at two properties: “Text” and “NavigateUrl”. The text is what is going to display on the page for the user to click. The NavigateUrl is the “Name” of the page that we created. Set this to “TrainingWebPartA”.
Now our user can go to the site, log in, and see WebPart B in the menu. If the user clicks on it, they will be directed to a page with a header, menu, footer, and WebPart B in the Body content area. In this WebPart B, there will now be a hyperlink at the top so the user can click it and be redirected to a similar page, but with WebPart A in the Body content area.
Now we want to edit WebPart A so that we call our stand alone Process created at the beginning of the training.
Change WebPart A to Call the Stand-Alone Process
Add a section to the bottom of WebPart A with a button. Remember to name everything. Since you can now navigate to WebPart A from the site, try using a full browser to test instead of the test tab.
Set up your button process by dragging a “Call” service from the “Process Services” Workshop in the Services list. Configure your “Call” service by giving it a “ProcessId”. Once you click into the “ProcessId” parameter, the “Process List on under the Recommended Values will display all Processes that are created. Find your process in this list.
Now your WebPart A has a button that calls your stand-alone Process. When the button is clicked, logs will be generated in the stand-alone process (if you were to open it from the “Work with Processes” home) and in the WebPart it is associated to.
Logs from WebPart A
Logs from Stand-Alone Process
This makes it easier when a Stand-Alone is called from within another entity. You can go to the outer entity and view the logs from the called process. It also makes it easy to find the logs from your process call instead of one initiated from another user browsing the site.
Edit the Stand-Alone Process
When we created our Stand-Alone Process, it was the first thing we created, so we didn’t set it up to be called by anything. Now, we want to go into it and edit it so that it can communicate with what it is called by.
You can easily open process calls by right-click a process “Call” service and selecting “Open Process”.
After selecting this option, it will create a new tab where you can work in this process.
Once in the stand-alone Process, add a Binary Decision after the SendEmail service. Configure it to ask either “Did the email fail?” or “Did the sendemail succeed?”. You could check if the WorkData/SendEmail node exists. You could also check if the WorkData/SendEmailException node exists. Make a decision about which you prefer and name your binary decision and configure it.
After your binary decision, it is a good practice to end all stand alone Processes with an Evaluate service called “Output” with two evals: “Success” and “Message”. This way, anywhere it is called from, it can be given input (if needed), we expect the process to do something, then we check the process call’s Output node and check if Success= “True”.
One of the Outputs is going to be the success case. The other will be an error case. When the process is successful, it will have Success=”True” and a Message of “Success”. When the process is unsuccessful, it will have Success=”Fals” and a Message that can be used to determine what went wrong. In this example, the only thing that should fail is the SendEmail service, which returns a message under the exception when it fails.
Reference Output Evaluate
Now that the Stand-Alone Process has an Output evaluate, we can change WebPart A’s button Process to reference it to confirm that is did not fail. Based on the result we can display a different message to the user.
For this, the Fail binary decision need to reference WorkData/[Call Service]/Output/Success. We will also use the Alert service. This service has only one parameter and is used to display a message to the user. Your message does not need to match a template, display a meaningful message to the user in the case of failure and success. Remember that if the Process fails, the Output evaluate also has a message and you could include this as part of your message if you wanted. If you did not want to display an unformatted message to the user and wanted full control over what text they are shown, you could leave the Output message out, but it would still be useful to a developer when debugging a SendEmail failure.