Test JMS activity template inputs You can test the input parameters of a custom JMS activity during its development without having to run the activity in a workflow context. Before you beginCreate input variables and map them to fields in the Execution Command form or provide actual values for these fields.Role required: web_service_admin, activity_admin, activity_creator About this task This test executes only the input parameters against an endpoint and not the pre-processing or post-processing scripts. It is not necessary to check out the activity to test it.Note: You can test input variables from any stage in the activity designer if you have provided enough information for Orchestration to contact the endpoint or host and return data. Typically, the Execution Command stage is the point at which your inputs are ready for testing. Procedure In the activity designer, proceed to the Execution Command stage. Define an appropriate MID Server, if requested. The test fails if the MID Server cannot be found or if it cannot connect to the target. Click Test Inputs. The list of input source variables appears. If you added default values for these variables, those values appear in the Substitute Value column. Mandatory variables are marked with a red star. In this example, the destination name in the JMS activity is a variable. When the variable is provided with a queue name, it returns the content of the message on that queue. Filter the variable list with these controls: All Inputs: Displays all input variables. This is the default view. Mandatory Inputs: Displays only mandatory input variables. Inputs Without Defaults: Shows input variables that do not have assigned default values. Reset values as needed. Reset default values: Replaces any test values set in this form with the default values, if they are present. Clear values: Clears all values in the input variable list, even if default values exist. When your test values are configured correctly, click OK. The system runs the values for all the inputs configured against the specified target and returns the resulting payload. The buttons in the Response form display different views of the payload. The entire payload appears in the Raw Output window. If all the credentials available to the activity fail, and the activity cannot authenticate on the target, a message describing the failure appears in the debugMessages tab. The format of the message is identical for all provider templates and displays the target IP address, the credential type (SSH in this example), and the details of all failed credentials, expressed as a JSON string.Figure 1. Credential debug message This MID Server stores the failed credentials in a blacklist cache for a period of 5 minutes. If you repeat the test within this time period, the credential debugger does not display the failed credentials and indicates that blacklisting is being applied. However, if you add or modify a credential for that provider template during the 5 minute blacklist window, and if all credentials are invalid, a test displays the entire list of failed credentials. After the 5 minutes has expired, any new attempt to re-run the invalid credentials results in a full listing. The value of the blacklist cache interval cannot be changed.Figure 2. Debug payload for blacklisted credentials Click Save for parsing rules to copy the entire payload to the parsing rules. This allows you to manually select values for the output variables directly from the payload. This action completely overwrites any previous payload that existed in the parsing rules. Click the X in the upper right corner of the window to close it.