I'm trying to integrate Microsoft Dynamics Nav 2009 R2 (Navision) with Sharepoint 2010 using external content types. I'm very new to both Dynamics Nav and to the Buisness Connectivity Service in Sharepoint 2010 and I can't get it to work.
I know that you can publish pages in Dynamics Nav as web services and I've published one of the demo pages as a web service and have successfully connected to it using Visual Studio (added it as a web reference). I've called the add and delete methods programmatically and it worked fine.
I opened sharepoint designer and tried to add an external content type. I set the "Data Source Type" to "WCF Service" and used the url to the web service (http://devel:7047/DynamicsNAV/WS/Page/Customer) in both "Service Metadata Url" and "Service EndPoint Url". When I try to connect to the web service I get an error saying "Cannot find any matching endpoint configuration".
Like I said earlier, I'm very new to both Microsoft Dynamics Nav and External Content Types in SharePoint. Information about Dynamics Nav and Sharepoint integration is hard to find and I'm feeling a bit lost. Will really appreciate if anyone can shed some light on how to integrate Dynamics Nav with SharePoint using BCS.
You'll have to forgive me since, while I know something about NAV web services, I know next to nothing about Sharepoint and BCS.
However, having said that, I do have a few pieces of advice that might be helpful: first and foremost, NAV web services are built on WCF and use the BasicHttpBinding. If you do some research on how to connect a WCF BasicHttpBinding service to BCS you might get some traction there. There is no fundamental difference between any standard BasicHttpBinding service and a NAV-specific web service.
You also mentioned that you were able to successfully connect to NAV web services in Visual Studio using a web reference. However, web reference proxies are built using the older "wsdl.exe" utility, and as such are only capable of working with classic SOAP web services. While BasicHttpBinding services are fully backwards-compatible with SOAP web services, there is still the issue of missing configuration settings that are unique to any WCF service. You really might want to consider using a service reference in visual studio and figuring out how to get it to work correctly with your published NAV web services. With that you can use the generated configuration settings to hopefully get a sense of what is missing in the sharepoint designer. My guess is the missing "endpoint configuration" error is telling you, in so many words, that some WCF-specific settings are necessary in sharepoint designer before you can connect to the NAV web service using a WCF proxy. It could be in the area of security for instance, since WCF gives you a much more granular level of control than classic SOAP. Again, the key I think is remembering that sharepoint needs a properly configured WCF endpoint whereas older web references do not. That's probably why you can get it to work in visual studio and not in sharepoint designer.
Just to give you an idea (not a lesson in "best practices"), when I create a service reference proxy in my NAV projects I often try to go with code-based configuration instead of the overly verbose file-based configuration (especially since we can't control the NAV service-tier endpoint bindings anyway). I use code similar to this to create a client connection (of course this is just pseudo-code and won't compile, you'll need to point to an actual service reference client proxy class for example, but this should give you an idea which WCF binding configuration parameters are necessary):
using System.Security.Principal;
using System.ServiceModel;
private void TestNavConnection(string url)
{
using (var ws = new NavServiceReference(GetBindingTransportCredentialOnly(), new EndpointAddress(url)))
{
ws.ClientCredentials.Windows.AllowNtlm = true;
ws.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation;
var record = ws.Read("XYZ");
}
}
private static BasicHttpBinding GetBindingTransportCredentialOnly()
{
var binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
binding.MaxReceivedMessageSize = 1048576;
return binding;
}
Hope this helps. Good luck!
Related
I don't have any code yet as I don't know where to start! I see on the web that I'd need to select
on the Access toolbar external data >> more >> data services. Then it asks to point to a xml config file. Which I don't have and would need to create. I have the connection string from a VB.net application.
sWIPConnString As String = "SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fake3465-vip.ent.agt.bb.ca)(PORT=41521))(CONNECT_DATA=(SERVICE_NAME=fictitious_service_name)));uid=APP_getinfo;pwd=thispassword;"
I'd have to convert that to an xml version. Any help would be appreciated!
Thank in advance
Pete
But those data services are not just any old plane jane web site. They are web sites that have installed, setup, and the developers of those web sites setup that data service connection. And these custom connections are NOT general web sites, and they are not general web services that many sites have. And they are not a web API written around say SOAP or some REST standard.
So unless that web site decided to adopt this Microsoft specific means and method to expose data, then you not be able to use this feature to simple connect to any old web site out of the blue. If you have a existing web site that exposes some web services? Then you have to use MSXML and consume that web data yourself. That option in Access is not some general purpose setting or feature that allows connection to any old web site - only ones that have created that web service written to the business connection options that Microsoft created.
It not clear if you planning to create some web services on the target web site (that would assume you're the developer of that web site), or you trying to consume existing web services that the given site exposes. Even in this 2nd case, those exposed web services or even REST calls has ZERO to do with the feature in Access.
so that feature is of only use for connecting to web sites that offer specific created connection based on that standard from Microsoft - it not a general web service consuming feature built into access and you can't use that feature as such.
How to make a web service call from Access? Well, it has ZERO to do with that feature. Here is a MSXML exmaple:
How to use XML web services in Access2007 which are built on Visual studio (2008/2010)
In our application a Service Reference was added to connect to a SOAP Web Service. When connecting to the Web Service we get an error. The owner of the web service told us that the error was caused because we use SOAP 1.2 and theirs web service only supports SOAP 1.1.
This answer mentions to add a textMassageEncoding setting in our custom binding. But it is not clear where to add this setting. Where should this setting been added?
Instead of adding a Service Reference add a Web Reference. I use VS 2013 (VS 2017 is exactly the same), right click on project name in Solution Explorer, select add then Service Reference, click Advanced button, click Add Web Reference at the bottom. Web references are a bit dated, but I use them all the time because I have a ton of legacy software, including android and iOS apps that use them. RESTful apis are typically the most used api these days.
I read couple of articles about creating custom WCF services for SharePoint 2010 and each suggests creating it under SharePoint project (as oppose to creating a separate WCF Application project or WCF Library). Also, I came across SharePoint WCF best practices.
So my question: is it possible to create a standalone WCF Service and have an option to deploy it inside of SharePoint (let's say I don't want this service to be a part of my wsp)? And what is the best practice?
thanks.
It has to be part of your wsp file if you are going to deploy it in a SharePoint web app. You can create a stand alone wcf service that can connect to a SharePoint site collection and you can also use the SharePoint Client Object Model to remotely connect to a SharePoint site collection. There are numerous walkthroughs on how to do this.
Here is a good starting point for the Client Object Model http://msdn.microsoft.com/en-us/library/ee537247.aspx
Base:
I have created a ASP.NET web part to be deployed to a Sharepoint 2010 site. This web part is using a external web service, a WCF service that is hosted else where, not on the same machine as the Sharepoint site. The web parts are installed on the sharepoint server using a CAB-file that is created via a deploy project.
Issue:
My issue is that I have web service binding configurations in the web.config of my ASP.NET web part solution that I need to modify based on what customer is using it, so I need to be able to modify my binding address after installation (or during).
Other:
I have seen solutions using the SPWebConfigModification, but I have no local installation of Sharepoint so that is not an option. I have also seen pure C# solution where the endpoint address is hard coded in the assembly, but this will prevent me from modifying the address after compilation of the web part. The best way would be to have an external txt/xml-file that I can use from my web part to get the endpoint address from, or a smart way of updating the sharepoint web.config not using SPWebConfigModification.
so...
any one have a awesome solution to my issue?
Can you use custom webpart properties that will contain the WCF endpoint information? This way you will be able to configure your webpart(s) after they are added to a page. The properties are reachable from the webpart code so you can generate the wcf proxy in the runtime with no custom config files in the solution.
this article might help you with the custom properties http://www.lamber.info/post/2010/05/21/How-do-I-create-custom-properties-in-Visual-Web-Parts.aspx
Editing web.config is almost always the wrong place to put something like this.
Maks answer is good and certainly the easiest option, if you want to store the address of the web service in one place to be used by multiple web part instances then this option may be better.
SO - What is a proper way to store site-level global variables in a SharePoint site?
Previously we have developed against the ReportServer/ReportService2005.asmx web service.
To access these web services, the MSDN documentation suggests the old .NET 2.0 based web service reference technologies. But we specifically chose to use the WCF (System.ServiceModel) technology to access this service. Regardless of whether you use .NET 2.0 WSDL or WCF Service References, in both cases proxy classes are generated to wrap the web service methods. Noteworthy, the proxy classes themselves will have different (but functionally equal) implementations. Ref: http://msdn.microsoft.com/en-us/library/ms155134.aspx
We have had great success with the WCF based service proxy against the ReportService2005 (for SSRS 2008). Recently, we were asked to do the same but to use the new ReportService2010 web service (for SQL Server 2008 R2) as the old ReportService2005.asmx/ReportService2006.asmx services have been deprecated. Ref: http://msdn.microsoft.com/en-us/library/ms154052.aspx
For context: The ReportService2006.asmx services are intended for using SSRS in a Sharepoint Integrated mode - presumably this has mostly to do with security (authentication/authorisation).
In the most simplest terms the new ReportService2010.asmx services are an almalgamation of the old ReportService2005.asmx and ReportService2006.asmx services, and you are now able to use the ReportService2010.asmx services for either "Native" or "SharePoint Integrated" scanarios.
After all that, my question is what else is different at an API level?
PS: I also found that SSRS2008R2 no longer supports Anonymous usage
For example I noticed that in the old services used to specify that the WCF Client security mode was set for "TransportCredentialOnly" using NTLM and passing your Username from the ClientCredentials. In contrast, the new 2010 services has the WCF Client security mode now set to "None" and the message still contains the UserName, but without any transport security (like NTLM).
OK, so I'm starting to guess that the act of integrating the 2005/2006 services (which likely used different authentication mechanisms) results in this change we see.
This though, has a direct impact on the API code in that previously you would be specifying the credential for the Client proxy as follows:
proxy.ClientCredentials.ClientCredential = yourCredential;
This no longer seems relevant. I also noticed that many of the proxy service methods now expect a TrustedUserHeader instance as the first parameter. For example:
proxy.CreateFolder( yourTrustedUserHeader, folder , ... );
From some documentation it appears to be implemented as a SOAP Header. This TrustedUserHeader object contains properties like UserName, UserToken, AnyAttr, etc. but I'm not sure what the proper usage pattern is. Unfortunately the MSDN documentation is equally useless in that I could not find clear guidance on this issue, nor do the MSDN documentaion use WCF ServiceModel to access the services.
Can anyone please provide some insight as to the appropriate way to now use the new Reporting Services 2010 interface?
Should I no longer set the "ClientCredentials" property, and instead create and instance of the "TrustedUserHeader"
Many thanks!
Jaans