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)
Related
I am new to Windows Azure and I have a question.
I have:
Web site which deployed to Windows Azure - The web site manage a table (add, edit, delete). I used this guide: Deploying an ASP.NET Web Application to a Windows Azure Web Site and SQL Database
Andorid application & iOS Application (Native Code).
Now, I want the mobile applications to get data (in JSON format) from the web site (and from the DB).
What is the best practice to do that?
I tried to create a Azure (WCF) Service (the project refrenced to the web site project) but I didn't succeded. If this is the way - Is anyone knows a good tutorial to do that?
Is there another option? Maybe from the web site itself?
Thank you very much,
Yuval
If you want to integrate with non-Microsoft technologies I suggest you take a look at the ASP.NET Web API which allows you to build REST services using content negotiation. Content negotiation allows your consumer to specify the format it requires (json, xml, ...).
To host the ASP.NET Web API in a Windows Azure Web Site you should take a look at Carlos' blog, he describes in detail what you need to do to make this work: Creating ASP.NET Web APIs on Azure Web Sites
Have you given ASP.NET Web API a look-see?
http://www.asp.net/web-api
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
I have two questions I hope I can get an answer for with regard to my service oriented application
I am creating a service oriented application where controls have no events, it's all done by calling services... that means the service url is written in my jQuery code, but this seems somehow not nice.... It's like what is the best option to save service urls?! I feel it's hard to maintain and not secure when it's written inside the page or inside javascript referenced file.
I am talking to a hosting company and they told me that I can host this application services on cloud server and the application on another servers.... not all in the same server, but my application services are self hosted, I mean the services are inside the application.... so to make things work as my hosting company wants, shall I host the restful services in IIS or how exactly?
Service URL must be in your page or script source file. It can be local address unless you are using cross domain calls and JSONP - cross domain calls requires absolute address. It is the same as any other web technology. If you want navigation to other page, you must provide URL. If you want some picture or css file you must provide URL. Security is up to you.
This will be the problem of cross domain calls. Normally JS calls can be done only to the same domain where the page is exposed. Once the application server is exposed on different domain name your calls will not work. To avoid that you must use JSONP (WCF 4 has support for that). Exposing rest services consumed by your application from self hosted application is strange. REST services are consumed by your clients - they are front-end services and should be part of your application hosted on front-end web server. Your back-end application server should not host anything directly accessible by your clients.
I have a WCF service that uses Membership for security. If I create a Silverlight Business Application It automatically links in with it and authenticates. How do I do the same with Windows Forms, and possibly XNA?
You can use Microsoft's Client Application Services http://msdn.microsoft.com/en-us/library/bb384297.aspx. I think that is what you are looking for.
Client application services make it easy for you to create Windows-based applications that use the Microsoft Ajax login, roles, and profile application services included in the Microsoft ASP.NET 2.0 AJAX Extensions. These services enable multiple Web and Windows-based applications to share user information and user-management functionality from a single server. For example, you can use these services to perform the following tasks:
I want to make use of some of the ASP.NET 3.5 capability within SharePoint 2007. In particular, I want to do the following:
Provide REST and maybe JSON through HTTP so that another product can consume SharePoint content.
Provide AJAX web parts within SharePoint. These will probably have little to no server side controls. Most content will be loaded using Javascript and hitting an external system (primarily not SharePoint) over HTTP that provides REST or JSON.
Provide this capability as a product. This is not a one-off solution for a single implementation.
My main concern is push-back from IT groups not wanting to change their SharePoint environment to allow for the product to work. So, I'd prefer to be able to say that what I'm doing is "supported by Microsoft", but I'm not sure that will be the case.
I realize that I could create a separate (non-SharePoint) web site on the SharePoint server(s) for WCF endpoints that provide SharePoint data to an external application. I would rather not do this because that won't help my web parts (if they need help) and that makes deployment harder. Proper SharePoint deployment will automatically have SharePoint update all necessary files (e.g., web.config) on any new web front end added to the farm and this wouldn't follow that pattern. In addition, I'd lose the ability to use SPContext.Current.
I have read much of Daniel Larson's book on Developing Service-Oriented AJAX Applications on the Microsoft Platform (good read, BTW), esp. Chapter 11 on extending SharePoint. He outlines WCF, ASMX, and HTTP Handler options and for the most part recommends the HTTP Handler option. It appears that the HTTP Handler option has minimal changes to web.config.
I have also seen a blogs on SharePoint as a WCF Host, SharePoint 2007 and the Thin .NET 3.5 Development Model, How to: Get up and running with .NET 3.5 in your SharePoint environment, and Enabling .NET 3.5 in SharePoint 2007 Sites, the Lazy Way. As well as the "Silverlight (.NET 3.5) Config Feature" (and maybe even the "Ajax.Config Feature") in the SharePoint 2007 Features CodePlex Project. It seems that all of these options do some fairly drastic changes to the web.config and may not be acceptable to potential customers.
What are the opinions out there on this? What about if I want to use the AJAX Control Toolkit (I've used this before in SharePoint, but it has been a while)?
Note that we probably could require SharePoint SP2 if that helps, but I don't think it does.
Note also that Silverlight is not a requirement for the SharePoint web parts, but allowing for it might be nice.
Your first point could be solved by a custom wrapper to the SharePoint web services, presenting the API that you want to present, rather than the generic web service.
Your second point, AJAX enabled pages and web parts, is already possible - how to enable AJAX in SharePoint.
.NET 3.5 Is supported in SharePoint (as of SP1 I believe), However you will not be able to get away from making web.config changes and installing .NET 3.5 on the servers - it will likely only be there if there are already AJAX web parts in use.
Aside from that what you are looking at is largely independent of SharePoint - If you can build something as an aspx page or asmx web service you should be able to deploy it to a SharePoint site.
If you want to avoid 3.5 installation issues altogether you should be able to build something totally separate - jQuery for the web parts (no server side components needed) and for getting data out of sharepoint build something that translates calls to the standard web services into a friendlier interface.