InfoPath Dev

Hello All,

Background:
- I have created a web service to return a unique ID.
- The web serice is running. I have tested it and the results are as expected.
- I have added the web service as a data source and can bind it to a control (although this isn't what I need to do).

Goal(what I am attempting to do):
- Call (Query?) the web service, only as needed, using Jscript.
- Pass a value to the web service and receive a value back.

I have researched this off and on for a few days, but haven't found any code examples that seem to do this. I found a C# example that mentioned re-querying, but the web service needs to only be called under specific circumstances.

Does anyone have an example of this or thoughts/suggestions that might be helpful?

Thanks in advance,
Troy

Hi Troy,
I seem to recall having seen a jscript snippet here or there showing how to do this. Have you checked MSDN and/or the InfoPath SDK?


Patrick Halstead [InfoPath MVP]
InfoPathDev

Patrick:

I have looked at MSDN, numerous books, the SDK, online posts, etc. Nothing seemed to put it all together. Here is what I have (it may not be pretty, but it seems to be working ...)

This web service takes a value to identify which type of id is being requested and then returns a unique id.

I defined the web service as a secondary data source within Infopath. In setting up the secondary data source, I specified Query:Yes and Submit:No. I also set up the value to be passed to the web service as part of the secondary data source set up.

<code snippet>

//Get a reference to the data object
var objTicketDO = XDocument.DataObjects("GetTicketNumber");

//Load the data objects DOM into a new variable so we can
//set the SelectionNamespaces to be able to access/navigate the nodes
var objDOM = objTicketDO.DOM;

//Access the web service Adapter (the QueryAdapter seems to be where
//data is passed back and forth
var objWSAdapter = objTicketDO.QueryAdapter;

//Execute the query to call the web service and get the id
objTicketDO.Query();

//This seems to be the return value
//This may be due to the way the web service is set up that this works
var objOutputNode = objWSAdapter.OutputLocation;
var tOutput = objOutputNode.text;

//Set up the namespaces. Otherwise, you can't access the prefixes --
//you get an undeclared namespace prefix
//Looking at the secondary data source within Infopath
//(how it defined it) told me what to use
objDOM.setProperty("SelectionNamespaces",
'xmlns:dfs="http://schemas.microsoft.com/office/infopath/2003/dataFormSolution" ' +
'xmlns:tns="http://www.internalsite.com/TicketDB"');

//Fetch the response node
//Access the text or nodeTypedValue as needed
var oTicketResponse =
objDOM.selectSingleNode("/dfs:myFields/dfs:dataFields/tns:GetTicketNumberResponse/tns:GetTicketNumberResult");

//Some clean up
objTicketDO = null;
objDOM = null;
objWSAdapter = null;


This link did provide some help -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipsdk/html/xdobjWebServiceAdapter_HV01021251.asp

I hope others find this helpful ...

Regards,
TroyE

Troy...your code looks solid. Personal preference, a lot people seem to execute thier data connections through rules, etc. in the form. I prefer to manually code my interaction with secondary data sources as you have discussed for a couple reasons:

1 - I can customize a secondary data source, like setting the timeout for a web service call. I cannot do that through a InfoPath pop-up.
2 - In my opinion, the InfoPath form is more maintainable because all of the data source execution is not embedded down in a rule that another developer may not know about.
3 - I can create re-useable functions to execute queries.

Just my two cents.

vt_asparagus:

Thanks for the feedback. I agree with the points that you have mentioned. I've been bitten a couple of times by non-obvious rules put in by other developers. For this reason, I tend to script actions where possible.

Regards,
Troy

I agree with how the rules situation can make things "hidden" a lot of times. I think Microsoft should implement some kind of "Rules Task Pane" where you can see all of the rules throughout the current view in one consolidated section. The same could be said about default value formulas.

In Excel a seperate "rules" or "formulas" panel wasn't necessary because you could just selected the cell and it would display the formula in the address bar-type thing at the top. However, now with InfoPath it probably takes about 7 clicks just to be able to see the rules of a certain control.

---------------
Matt Faus

Matt, great idea! InfoPath rules are hard to debug and a tool to step through them would be very cool, but would require hooking InfoPath.exe itself which would require an object model that doesn't exist ... Anyway, debugging declarative logic is a big issue for InfoPath. It's easy to do stuff without code, but it's hard to figure out why it doesn't work. However, the rules do function correctly so it's likely just a matter of trying stuff out over and over again and making sure you have the write order and evaluation conditions.

Patrick Halstead [InfoPath MVP]
InfoPathDev

I thought that was a great idea too.