Configure the Validation API in DRE

This API allows Dameware Remote Everywhere (DRE)customers to pre-process the data gathered through the DRE Applet prior to the creation of a support request. This pre-processing action provides the ability to validate the client’s data, forward support requests to the right departments or technicians, compare information with the database and automatically identify a client.

The pre-processing acts as a “web service”, apart from the DRE structure, that must be in compliance with the terms of the present document. That service will be published by the DRE client on its own infrastructure and should be available through via internet access. The corresponding URL is configured by the client. The communication between the DRE Applet and the service can be executed in HTTP - or HTTPS for stronger security.

Input Parameters

These parameters can be submitted by GET or by POST, depending on the options configured in the DRE Admin Area. Clicking the SUBMIT button to send this form and gather client’s data from the Applet and send it to the web service.

Parameter	Type	Description
customer_name	String	Contains the client's name, as stated in the applet.
customer_number	String	Contains the client's number, as stated in the applet.
customer_email	String	Contains the client's email, as stated in the applet.
problem_description	String	Contains the problem's description, as stated in the applet.
computer_name	String	Contains the computer's name where the applet is being executed.
computer_domain	String	Contains the domain's name where the applet is being executed.
submit_count	Integer	Contains the number of times the information was submitted. The computing of this variable, altered every time the submit button is pressed, is exclusive and internal to the Applet. The value starts at 0.
data_variable	String	Contains the data_variable field value, as sent in response to the query prior to the pre-validation. This variable can be used to storage status information between the various queries. This value won't be stored together with the support session information, neither will it be processed by the Applet. This field has a max limit of 2048 characters.

Example - https://www.john-doe-and-sons.com/webservice/precheck.php?customer_name=John&customer_numbe r=C12345678&customer email=john@somewhere.com&problem description=My%20Problem&comput er_name=My%20PC&computer domain=MY%20Domain&submit count=0& data variable=

Response Format

This response will be interpreted by the DRE Applet and controls the Applet’s form behavior. Below is a list of the available tags for the response. Depending on the context, not all tags can be specified or will be interpreted simultaneously.

<response>
	<submit_support_request>true|false</submit_support_request>
	<request_route>
		<department>...department id or deparment name..</department> 
		<technician>...technician id or technician username...</technician>
	</request_route>
	<customer_data>
		<customer_name>...customer name...</customer_name>
		<customer_email>...customer email...</customer_email>
		<customer_number>...customer number...</customer_number>
		<problem_description>...problem description...</problem_description>
		<custom_text_field_name>...custom text field name...</custom_text_field_name> <custom_text_field_data>...custom text field data...</custom_text_field_data>
	</customer_data>
	<custom_message>
		<message_type>...MSG_OKIMSG_YESNO|MSG_OKCANCEL</message_type>
		<message_icon>...ICON_ERROR ICON_INFORMATION ICON_QUESTION...</message_icon> <message_ok_url>...</message_ok_url>
		<message_cancel_url>...</message_cancel_url>
		<message_yes_url>...</message_yes_url>
		<message_no_url>...</message_no_url>
		<message_text>...message text...</message_text>
	</custom_message>
	<data_variable>...general purpose variable...</data_variable>
	<focus_field>...FLD_CNAME|FLD_CEMAIL FLD_CNUMBER...</focus_field>
	<close_application>true|false</close_application>
</response>

Tags

SUBMIT_SUPPORT_REQUEST (Mandatory)

This tag is mandatory and determines whether the support request should be created or not. The supported values are TRUE and FALSE.

REQUEST_ROUTE (Optional)

This tag is mandatory and determines whether the support request should be created or not . The supported values are TRUE and FALSE. To forward a request to a specific department, this tag should include the department sub-tag specifying the respective department’s numeric ID. The ID can be found in the DRE Admin Area. Alternatively, it’s possible to specify the department’s name.

Forwarding a request to a specific technician obeys the same logic. The tag should include a technician sub-tag specifying the respective technician’s numeric ID. Alternatively, it’s possible to specify the technician’s user name. If this tag is not specified, the request forwarding will take place as defined during the DRE Applet creation.

CUSTOMER_DATA (Optional)

This tag is optional and allows the replacement of the client’s data values as they were submitted in the creation of a support request. The data will be visible to technicians in the DRE console.

CUSTOM_MESSAGE (Optional)

This tag is optional. It specifies that a pop-up will be activated after the query as been submitted for pre-processing to the pre-validation “web service”. This pop-up can present error messages, warnings, or any other messages. For example, it can warn the client that they need to fill out a specific form field or that the stated client’s number is not accurate.

The message_type and message_text tags are mandatory. They specify the pop-up type and what message will be presented to the user. The supported message types are MSG_OK, MSG_YESNO, MSG_OKCANCEL. MSG_OK specifies that an OK button pop-up will be activated. MSG_YESNO specifies that a YES or NO button pop-up will be activated. MSG_OKCANCEL specifies that both an OK button and a CANCEL button pop-up will be activated, respectively.

The message_ok_url, message_cancel_url, message_yes_url, and message_no_url fields are optional and direct the client to a URL after pressing a specific button. The message_icon field allows the control of the existing icon placed in the pop-up that is presented to the client. The supported values are ICON_ERROR, ICON_INFORMATION, ICON_WARNING, and ICON_QUESTION. The pop-up can be showed when the support request is submitted or when an error occurs. In the first event, the pop-up is displayed before the creation of the support request.

FOCUS_FIELD (Optional)

This tag is optional and allows for a specific field on the client’s data form to become active. This tag is useful to deal with validation errors in specific form fields when used with the custom_message tag. The supported values for this tag are FLD_CNAME, FLD_CEMAIL, FLD_CNUMBER, and FLD_PROBDESC. These fields will place the cursor on the Client's Name, Client's Email, Client's Number, and Problem Description fields, respectively.

CLOSE_APPLICATION (Optional)

This tag is optional and allows to close the BeAnywhere Support Express Applet. It will only be executed when submit_support_request is FALSE . The Applet shut down will be executed only after a pop-up is presented to the customer, if this is specified in the response.

Example 1

Here is a response example, where a data pre-validation has failed due to an invalid client number. An error message is presented to the client, indicating the situation.

<response>
	<submit_support_request>false</submit_support_request>
	<custom_message>
		<message_type>MSG_OK </message_type>
		<message_icon>MSG_ERROR</message_icon>
		<message_text>Invalid Client Number!</message_text>
	</custom_message>
	<focus_field>FLD_CNUMBER</focus_field>
</response>

Example 2

Here is a response example where the data pre-validation has been successfully executed and the request will be sent to a support department.

<response>
	<submit_support_request>true</submit_support_request>
	<request_route>
		<department>Support Department</department>
	</request_route>
</response>