Replacing custom scripts with the SDK Toolkit extension
Recently, I talked about the new SDK Toolkit Extension in Dovetail Carrier, which allows for executing methods within the Dovetail SDK Toolkits, without writing any code.
Once that was released, I was able to remove some custom scripts from our own production environment, and replaced them with this new SDK Toolkit extension.
Change Status
This is the business rule that we has in place:
| Object Type | Case |
| Rule Name/Description | When a customer logs a note via SelfService, change the case status to Customer Update |
| Start Events | Log Note |
| Cancel Event | None |
| Conditions | Logger = SelfService |
| Action Title | Change Status |
| Create Activity Log Entry? | true (checked) |
| Who to Notify | no one (leave empty) |
| Start Action | 0 minutes From Event Creation Using Elapsed Time |
| Repeat | Never |
| Message Type | Command Line |
| Message | C:\Dovetail\custom\RuleManagerActions\ChgStatus\ChangeCaseStatus.bat [Object ID] ‘Customer Status changed automatically due to action within SelfService’ |
Notice that it’s calling a custom command line script (ChangeCaseStatus.bat), which is actually a wrapper that calls ChangeCaseStatus.ps1 (a PowerShell script).
Now that we have the SDK Toolkit Extension available, we can change that rule to this:
| Message Type | Carrier Message |
| Message | Type=CallToolkit Toolkit=Support Method=ChangeCaseStatus CaseIdNum=[Case ID] NewStatus=Customer Update Notes=Status changed automatically due to action within SelfService |
Notice that it creates a Carrier Message of type CallToolkit, and calls the ChangeCaseStatus method.
Initial Response
This is the business rule that we has in place:
| Object Type | Case |
| Rule Name/Description | Set Initial Response on a case |
| Start Events | Log Email, Phone Log |
| Cancel Event | None |
| Conditions | Logger != SelfService Logger != Dovetail Responded To = 0 |
| Action Title | Initial response |
| Create Activity Log Entry? | true (checked) |
| Who to Notify | no one (leave empty) |
| Start Action | 0 minutes From Event Creation Using Elapsed Time |
| Repeat | Never |
| Message Type | Command Line |
| Message | C:\Dovetail\custom\RuleManagerActions\InitialResponse\InitialResponse.bat [Object ID], [Logger] |
Notice that it’s calling a custom command line script (InitialResponse.bat), which is actually a wrapper that calls InitialResponse.ps1 (a PowerShell script).
Now that we have the SDK Toolkit Extension available, we can change that rule to this:
| Message Type | Carrier Message |
| Message | type=CallToolkit toolkit=Support method=InitialResponse caseIDNum=[Case ID] UserName=[Logger] |
Notice that it creates a Carrier Message of type CallToolkit, and calls the InitialResponse method.
Less Moving Parts, Better Performance, and Reliability
In the past, if I wanted to have a business rule invoke an API, I would create the business rule, have that business rule call a BAT file, that BAT file would call script (such as a powershell script), and have that powershell script fire up the SDK, and then invoke the API. This is exactly what the old versions of the business rules did.
Every time that script was called, it would have to establish a new database connection, log in, perform application initialization (which would cache a bunch of data), perform session initialization (which would also cache a bunch of data), then invoke the API, then shut down. I would also have to deal with separate logging and log files for each script. I also needed to worry about deploying these scripts to my test and production environments.
Now, I simply have the business rule send a message to Carrier. Carrier is already logged in to the database, it already has all of its needed data cached, it already has logging setup and configured. And there aren’t any files that need to be deployed.
So now I have less custom code, less work to do myself, there are fewer processes running on the server, and my operations execute faster.
Plus, I get the reliability built into messaging. For example, if Carrier is temporarily down, the message won’t be lost. It will remain in the MSMQ queue, and will be picked up when Carrier restarts.
Summary
With the SDK Toolkit Extension, we’ve opened up a new avenue for performing custom actions within your system, and doing it without writing or deploying code.
It’s a great opportunity to delete some code as well, and simplify your system.
Dig this?
Sign up to get information like this delivered right to your inbox.
