Skip to main content

The Command Action Template

Fernando Lucas Pérez
  • Updated

Overview

One of the most powerful elements in CRM.designer is the Command Action Template. This Action Template allows users to invoke different JS commands from application menus, context menus, or processes.

Information

Commands are not exclusive to CRM.web, and are implemented in the form of user-readable JS files stored under ...\update.web\web\scripts\crm\. In CRM.designer, Commands can be invoked via the Command Action Template, which supports a variety of inputs.

The supported inputs for Command Action Templates are the following:

  • Command: this is the name of the Command being executed.
  • CommandArguments: this is where optional parameters are introduced. Which arguments will be supported will change for each Command, and it will be necessary to study the available documentation and/or the Command's code.
  • Record: this is where records supplied as parameters would be introduced. Again, whether this will be supported or required will depend on the specific Command.
  • RecordSet: another optional parameter. Please refer to recordSet for more detailed information.
  • $type and $using: types and resources (in JSON form) to be loaded before execution.

 

Debugging Commands

Like most elements in ACRM, Commands can be thoroughly customized. Therefore, one of the most important steps when providing support for issues and queries related to Commands will be to find out whether a given Command exists for the base product, or is instead a customer-specific customization.

This can be easily verified by checking on a vanilla test environment. As always, make sure to verify in environments for all three main templates (LSI, ISI, and FSI) before concluding that a certain Command does not exist in a vanilla ACRM environment.

Understanding a Command

Once you have concluded that a Command is not custom, and therefore troubleshooting falls under the scope of Central Support, you will need to understand exactly what it does before you can provide an answer or solution to the customer.

The first step will be to verify whether any documentation exists on the particular Command and its options, for which you may consult the usual online documentation, as well as the documentation available in the Worx portal for the latest ACRM version.

Often, however, no documentation will have been made available regarding a certain Command. If this is the case, you will need to analyze the Command's source code to understand what it does and learn what may be causing the customer's issue. Note that the ACRM SDK documentation contains all relevant information to help you understand any given Command's JS code.

Proposing a solution

Finally, if you determine that the reported issue is the intended design for a certain command, you will need to inform the customer accordingly, and suggest any of the following:

  • Any alternatives not based on any commands. Occasionally, what the customer requests is not possible through the use of commands, but there are alternatives that can help them achieve a similar goal by using the different elements of CRM.designer in a different manner.
  • Any modification in CRM.designer that changes how the Command behaves. The behavior of a command may be modified without changing the Command's code by changing the elements that it uses. For example, a command may be hard-coded to invoke a certain Search&List for a given Info Area, which the customer may modify for a certain configuration, if required.
  • Customizing the Command's source code, or developing a new command that may be used by the customer.
Note: when proposing solutions, bear in mind that customization requests fall outside the scope of Customer Support, and you will need to direct the customers as indicated in the ACRM routing table.

Related articles