After pasting in the code for the worker, click “Run". The worker runs and you can see the result in the Execution Results pane in the bottom right hand side of your screen:
Figure 7 - Result of the first execution.
You can see that the script returned an object containing:
- status: The script determines the value for this property. In this result, 2 corresponds to the enum property UploadStatus.UPLOAD_STOP
- message: The script determines this property also. We see that the repo path does not match the regex value.
- modifiedRepoPath: This property is set with the value of data.metadata.repoPath that we received from the payload as we want to keep the original value.
- executionStatus: The worker service determines this value. The value tells you that the script was successfully executed.
Now before we enable our worker, we want to test it a bit more, to ensure that once enabled we will not block all uploads by mistake. According to the regex we should be able to upload a file with the following repoPath value: “org/company/package1/subPackage/webapp.war”. To simulate this upload request we can use the data structure in the upper right area and modify its path property as shown in the figure below:
Figure 8 - Mock of the payload for testing.
If we press the “Run” button again we will see that the status value has changed to 1 (which equals UploadStatus.UPLOAD_PROCEED) and the message tells us that the repoPath value is acceptable and the worker can be executed:
Figure 9 - Result of the second execution, this time we provide a value to data.metadata.repoPath.path (see figure 8 above).
So far so good!
Let’s step forward by giving a name to our worker as in the screenshot:
Figure 10 - Setting the name of the worker.
Then click on “Save” and “Close”. The Workers page should now show your new configured worker :
Figure 11 - Display of the list of configured workers.