A common workflow is to have a business rule fire, and that business rule will send Dovetail Carrier a message.
For example, when a customer updates a case via SelfService, we can have a business rule fire that sends an SDK Toolkit message to Carrier, and Carrier will change the case status to “Customer Update”.
Complete end-to-end Testing
When I’m putting this all together, and testing it out, a full integration test would be to log into SelfService, and log a note to a case. That would cause Rulemanager to fire a business rule which would send the message to Carrier, then Carrier can do its thing. So I have multiple apps in play here:
- Dovetail Agent, for setting up the business rule
- Dovetail SelfService, which is how the customer updates a case
- Dovetail Rulemanager, which processes the business rule and sends the message to Carrier
- Dovetail Carrier, which receives the message and performs the Change Status
When I’m first setting this all up, I can simplify all this, and test using just 1 app, rather than dealing with 4.
I like to be able to throw a message into Carrier’s queue to get processed, and test that it’s doing what I expect.
I can easily do this using the publish.exe utility. This executable will simply take the message content as an input parameter, and publish that message to Carrier. I mentioned this executable before, in the context of custom actions, and we provide this app (and the source code for it) as an example of how you can build your own app that publishes messages to Carrier.
More and more I’ve found myself using this utility to push messages to Carrier for testing purposes.
This way I can just test the Carrier message piece, and not have to worry about the other 3 apps. This makes testing much easier and faster.
Check out the Dovetail Carrier Customizations site for more details on downloading the exe and its source code.
From a command line, I can simply call publish.exe, and pass in the message. Note the use of \n to indicate a newline.
Here’s an example where I’m publishing a message into the Carrier queue so that it changes the status of a case.
publish.exe "Type=CallToolkit\n Toolkit=Support\n Method=ChangeCaseStatus\n CaseIdNum=4305\n NewStatus=Working"
Once I have the basic message working, then I can start adding in other parameters, or testing variations as needed.
The Carrier logs allow me to track down any errors. For example, here’s the logs showing that the message was received and processed, but I gave it an invalid status.
Carrier message received: Type=CallToolkit\nToolkit=Support\nMethod=ChangeCaseStatus\nCaseIdNum=4305\nNewStatus=Customer Update
Resolved message data for: Carrier.Extensions.SDK.CallToolkit
Invocation request received:
"NewStatus": "Customer Update"
Resolved toolkit: FChoice.Toolkits.Clarify.Support.SupportToolkit
Resolved ChangeCaseStatus to Carrier.Extensions.SDK.DefaultToolkitInvocationPolicy
ERROR FChoice.Foundation.Clarify.ClarifyException -
FChoice.Foundation.Clarify.ClarifyException: (15126) Element 'Customer Update' in list 'Open' does not exist.
Iterate and Test Quickly
By reducing my development/test footprint to only Carrier, I can more quickly iterate over different message formats, without involving Agent or Rulemanager.
Once everything is good with my Carrier message, I can then bring my other apps into play (such as Agent, Rulemanager and SelfService)