How To Example: Insert Encrypted Data Through Edge Proxy from ServiceNow InstanceSummaryThis article presents a use case for inserting encrypted data through the Edge proxy from the ServiceNow instance. The use case is different from most of the Edge proxy use cases where the data is encrypted from a web browser. In this use case, the table is the Problem table, with the short_description field to be encrypted. The data to be encrypted will be sent via a REST web service from the instance, then routed by mid server through the Edge proxy for encryption. This is a simple example, intended only to show how the data from the server side can be encrypted through the Edge proxy.InstructionsThe steps required to make this approach work: Required plugins: com.glide.edgeencryption com.glide.edgeencryption.core com.glide.encryption.core com.glide.encryption Setup field encryption configuration: Navigate to Edge Encryption Configuration > Encryption Configurations > Create New.Complete the form by selecting the Problem table and the short_description column. Setup REST web service: On the proxy, navigate to System Web Services > Outbound > REST Message.Create a new REST Message, ensuring that the endpoint is the Edge proxy endpoint. In this example, the endpoint is https://<proxy_url>/api/now/table/problem/6632130c730123002728660c4cf6a734, where the sys_id is 6632130c730123002728660c4cf6a734, which is the record that needs to be updated. Click the Authentication tab, selecting an Authentication type of Basic and Basic auth profile admin.In the HTTP Methods section, create a new PATCH method.On the HTTP Method patch, click the HTTP Request tab and enter the mid server name in the Use MID Server field. Figure 1. Sample REST Message Figure 2. Sample HTTP Method Setup the encryption rule via the Edge proxy: In order to encrypt the data from REST web service, you must create a custom encryption rule in the Edge proxy to intercept the REST request from the instance and apply it to encrypt the data. On the Edge proxy, navigate to Edge Encryption Configuration > Rules.Create a new rule for the HTTP Patch request.Condition – the sys_id 6632130c730123002728660c4cf6a734 identifies the record to be updated. function PatchProblemAPICondition(request) { if (request.path.indexOf('api/now/table/problem/6632130c730123002728660c4cf6a734') > -1 && request.contentType.indexOf('json')) { return true; } return false; }} Action function PatchProblemAPIAction(request) { var tableName = 'problem'; var jsonContent = request.getAsJsonContent(); var jsonNodeIterator = jsonContent.iterator(); while (jsonNodeIterator.hasNext()) { var jsonNode = jsonNodeIterator.next(); var fieldName = jsonNode.getName(); jsonNode.valueFor(tableName, fieldName); } } Figure 3. Sample Edge Encryption Rule Verify that the entire flow works via Fix Scripts: The use case is to update the problem statement field in the Problem table using the PRB0001002 record in the Problem table as an example. The original problem statement was “Unable to connect to Wifi…”. The REST patch service will update the statement to “Unable to connect to Wifi again…”. Navigate to System Definition > Fix Scripts.Create a Fix Script to invoke the REST patch service defined in step 3. gs.info("Test Table API Start"); try { var request = new sn_ws.RESTMessageV2('Test Table Api', 'patch'); request.setRequestBody("{\"short_description\":\"Unable to connect to Wifi again...\"}"); //if the message is configured to communicate through ECC queue, either //by setting a MID server or calling executeAsync, one needs to set skip_sensor //to true. Otherwise, one may get an intermittent error that the response body is null request.setEccParameter('skip_sensor', true); var response = request.execute(); var responseBody = response.getBody(); var httpStatus = response.getStatusCode(); gs.info("httpStatus="+httpStatus); gs.info("responseBody="+responseBody); } catch(ex) { var message = ex.message; gs.print(message); } gs.info("Test Table API End"); Click Run Fix Script to invoke the REST patch service.Click the Show Progress Workers link to check the result.Go to: https://<proxy_url>/sp?id=form&table=problem&sys_id=6632130c730123002728660c4cf6a734&view=Default viewThe problem statement is updated to “Unable to connect to Wifi again…”.Go to: https://<instance_url>/sp?id=form&table=problem&sys_id=6632130c730123002728660c4cf6a734&view=Default viewThe problem statement is encrypted Figure 4. Sample Fix Script Verify that the custom encryption rule works via Postman: This is a simple way to make a Postman request to verify whether or not the custom encryption rule works. Sample patch request curl --location --request PATCH 'https://<proxy_url> /api/now/table/problem/6632130c730123002728660c4cf6a734' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --data-raw '{"short_description":"Unable to connect to Wifi again..."}' Go to: https://<proxy_url>/sp?id=form&table=problem&sys_id=6632130c730123002728660c4cf6a734&view=Default viewThe problem statement is updated to “Unable to connect to Wifi again…”.Go to: https://<instance_url>/sp?id=form&table=problem&sys_id=6632130c730123002728660c4cf6a734&view=Default viewThe problem statement is encrypted. Possible error cases: If you see the error message "Invalid attempt to insert non-encrypted data into field: short_description in table: problem,” the possible causes are: The REST request endpoint was pointing to the instance instead of the Edge proxy.The Edge Encryption rule was not able to match or parse the request correctly.