Custom eConnect XML Node–Procedure or function expects parameter, which was not supplied
Custom XML nodes error with parameters
It is possible to run your own custom stored procedures from eConnect, by passing in parameters via a custom XML nodes. I have explained this technique in a previous post, there is more information on MSDN too:
- This Blog: Using custom nodes in eConnect XML to run stored procedures
- MSDN: eConnect Custom XML Nodes
When developing a new Custom XML node it may be that the following error is encountered
Procedure or function expects parameter, which was not supplied
This may be due to misconfiguration of the stored procedure parameters or XML node names.
Remember:
- Prefix the stored procedure parameter names with I_v (Input Variable), so a parameter named “cardnumber” would become @I_Vcardnumber in the stored procedure
- Pass in the eConnect XML document node like this (no prefix):
<cardnumber>4929000000006</cardnumber>
Dynamics GP Integration Service
The Dynamics GP Integration Service, a windows service that provides an econnect end point service, if this is how the documents are being pushed through to GP, if using this then read on.
eConnect for Microsoft Dynamics GP 2013 Integration Service
Cause
I have seen this behaviour a few times now. The error stated above occurs, using SQL profiler to view the SQL conversation between eConnect and the stored procedure, it looks like the parameters are being passed with the value of “default” rather than the expected values from XML.
Putting a break point on the application and inspecting the source eConnect XML document, it seems the XML looks ok, with all the data in the relevant nodes of the document.
-So the nodes are not being extracted by eConnect and passed as the SQL parameters – why?
Solution
If this is being experienced, I expect that the stored procedure has been edited and/or the fields in the document have been edited, perhaps adding an extra field, changing a parameter name? What I have found is that the Integration Service seems to cache the profile of the SQL stored procedure parameters. I can guess this would be a good idea for performance reasons, but it means if a change is made to custom XML nodes or procedures there of, then the service must be restarted.
Restarting the service resets the cache and suddenly with no further changes the custom nodes behave correctly again! This cache behaviour can cause some serious head scratching until it is revealed what is happening.
not your issue?
There is another solution from another cause for this error, the post on Steve Endow’s blog explains:
Mysterious eConnect Error: The stored procedure does not exist. Watch your schemas!