ABW - No ContractActionParameter audits recorded in SQL Database when using REST or Messaging APIs

[Stuart Corrans]

Hopefully I've missed something obvious (perhaps an explicit "Audit Parameters" flag or such), but I've noted that when using the samples from both the REST Api and the Service Bus Messaging API that the parameters passed to the actions are not being audited in the SQL ContractActionParameters table (although I am confident that the parameters themselves are being passed across to ethereum, as my Solidity contracts respond to the parameter values).

As a result of the missed audit, the contract actions on the UI don't show the parameter values.

Difference between Contract Action audits initiated from UI (Left) and Message / REST (Right)

I'm using the 1.0 workbench upgraded with the v 1.1 script.

The missing data (in Contract 81, above) is clear from SQL - just the data added from the ABW Web UI is present in the audit.

SELECT * from [dbo].[ContractActionParameter] cap inner join [dbo].[ContractAction] ca on cap.ContractActionId = ca.Id
WHERE ca.ContractId = 81

[#2]

You may have missed something with the configuration. Please feel free to send me your config and solidity to zeyadr [at] microsoft [dot] com

[#3]

The samples for UI, RestAPI and message based Action creation above are from the same application (the Hello Workbench sample). But you're right, according to the architecture diagram all commands flow across the activityHub Service Bus queue, so unless the UI is breaking architecture and writing to the Sql database, there must be something different in my UI, and the Rest / Direct message based actions.

I'll temporarily turn off my the Worker VM and dissect the messages placed on the Service Bus by the UI vs the ones I'm creating.

[#4]

Let me know what you find, or send me an email and we can help debug. 

[#5]

My understanding of the ABW architecture was wrong - the REST API (and possibly the UI) also apparently write to the Sql Database, in advance of sending messages to the worker via the Service Bus, so when using the Messaging API, you would need to either subscribe to the Event Grid or poll the Sql database, in order to locate the Contract Id (on create) and Contract Action Id (on transactions), which then needs to be provided on further contract interactions when using the Service Bus messaging approach.