Connecting InfoPath 2007 to WCF services
WCF Security and InfoPath 2007 have pretty poor integration,
which means that it basically doesn’t work and some hacks have been necessary
to get the forms to talk to the services. Below is a list of the required steps
to ensure future services can be consumed by InfoPath forms.
WCF endpoints must implement the following in order to be
consumed from within an InfoPath form:
Binding
<service
name="CustomerResponse.IssueService"
behaviorConfiguration="CustomerResponse.IssueServiceBehavior">
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="Binding1"
contract="CustomerResponse.IIssueService" />
</service>
Security
<security
mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
If the clientCredentialType is set to NTLM then forms
services will work fine, but in InfoPath 2007 client you will be prompted
continually to enter credentials. This is especially annoying when testing the
form before publishing.
Within the InfoPath form, in order to consume this service,
a Data Connection must be made to the service, and then converted to a .udcx
file; storing the file in a Data Connection Library in the target SharePoint
site. Once the udcx file has been created, the following security credentials
must be inserted, otherwise the service will not authenticate and an error will
occur.
<udc:Authentication>
<udc:UseExplicit
CredentialType="NTLM">
<udc:UserId>a valid user</udc:UserId>
<udc:Password>password</udc:Password>
</udc:UseExplicit>
</udc:Authentication>
Idiosyncrasies of WCF/Entity Framework
Connecting to Services exposing message entities
generated by entity framework (EF) has also involved some strange behaviour.
Due to the nature of the messages created by EF, I have not been able to find a
way to call a create method from an InfoPath form – without inserting any code.
To get round this, the solution was to insert a stub record into the database
prior to opening the form; negating the need for an insert.