I've been tasked to create an API where a web page (developed externally) should be able to communicate with a CRM system. I've looked into the CRM SDK and created a couple of C# classes that perform some basic operations to get a feeling of it, but my main issue now is what should I give the web page's developer so that he can use what I have. Does it have to be a REST/SOAP API hosted on the domain of the CRM so that the web page can send queries or can I create a DLL from the c# project and give that to the web page's developer?
In fact, how would it work out if it's a REST API if CRM is hosted by Dynamics/Microsoft?
You are looking to create a wrapper around the Dynamics CRM Api to support development of an application that interfaces with Dynamics CRM. There are two ways to do this:
Create a hosted web service.
Generate a DLL with public methods.
If you are okay with the developer-user having to configure a connection string for Dynamics CRM and the application is being developed in a .NET language and the CRM server is addressable from the location where the application runs than # 2, generate a DLL with public methods, is the easier answer.
If any of those are not true you are likely to find that # 1, a hosted web service, is a better fit.
Related
I have a small question which ends in a big topic.
Is it possible - and yes how - to use C# code in a SharePoint 2013 Hosted App?
I tried to have a .asmx file within my project.
Then I get this error.
#"Error 1
CorrelationId: 9c1ea930-a131-4f5b-bff5-8a1a61fe34d9
ErrorDetail: There was a problem with activating the app web definition.
ErrorType: App
ErrorTypeName: App Related
ExceptionMessage: Microsoft.SharePoint.SPException: Exception from HRESULT: 0x81070964 ---> System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x81070964
And then I tried a few tutorials like...
http://chuvash.eu/2012/02/13/custom-httphandler-in-sharepoint-for-getting-dynamic-javascript-code/
http://blogs.msdn.com/b/kaevans/archive/2010/08/04/deploying-an-asp-net-httphandler-to-sharepoint-2010.aspx
http://social.technet.microsoft.com/wiki/contents/articles/24194.sharepoint-2013-create-a-custom-wcf-rest-service-hosted-in-sharepoint-and-deployed-in-a-wsp.aspx
But sometimes I didn't understand correctly or sometime I have other problems during compile everything.
I had a problem with getting assembly id/name, too. Because there was no compiled DDL File for the project.
What I want in general?
A .app file with a SP Hosted App (for SP 2013) which includes a web service for SP Client Object Model.
So I thinking about using the "default.aspx" with CodeBehind. So I could execute scripts "behind" the aspx. But then it couldn't find the assembly... Or there was something else.
Could anyone help me? If you have some ideas you could !please! provide them to me. Thank's!
SharePoint hosted Apps doesn't allow server side code to be excuted on the server, this is the whole idea of SharePoint Apps, nothing should be executed in the SharePoint Front End Servers. Unlike Farm solutions, SharePoint Hosted Apps runs on the client and can only access SharePoint resources through a predefined set of services that can be called either using REST or JSOM.
If you need a custom code, you can create a WCF service, deploy it under ISAPI and call it from your App, but this will not be doable in SharePoint online.
As for your question, you can use ASPX pages of course, but you will never put a code behind for it, as these pages are stored in a Pages Library and by design, it is stored in the content DB, so any code execution is denied.
Only aspx pages that are stored on hard disk like the _layouts pages can have a code behind.
SharePoint App runs in client context. You can create SharePoint App just using JS, HTML, CSS, JSOM. You cannot use C# for App (excluding CSOM, you can use it for creation remote event receiver for example)
If you need to implement some functionality to on-premise version of SharePoint, use traditional server-side solutions, not App.
It's important to understand the difference between SharePoint-hosted Apps and Provider-hosted Apps:
SharePoint-hosted Apps
SharePoint-hosted apps, or apps where all components are hosted on either an on-premises or Office 365 SharePoint farm. SharePoint-hosted apps are installed on a SharePoint 2013 website, called the host web. They have their resources hosted on an isolated subsite of a host web, called the app web. The App is created using HTML/JavaScript with CSOM or REST calls
Provider hosted apps
Provider-hosted apps for SharePoint include components that are deployed and hosted outside the SharePoint farm. They are installed to the host web, but their remote components are hosted on another server. The App run in a server that is external to SharePoint's. It has its own infrastructure and the Provider is responsible for keeping it running. They allow you to use Server Side code and uses the .NET CSOM.
This image will give you an overview of different Hosting solutions:
Visit the following link for more information:
https://msdn.microsoft.com/en-us/library/office/fp179887(v=office.15).aspx
The SharePoint Add-in model uses ASPX pages, which can also include ASPX controls. However any methods called are restricted to client-side scripting - i.e. JavaScript and SharePoint's JSOM (JavaScript Object Model), which is a subset of the Client Side Object Model.
I need to design an HTML 5 responsive, and simple app that should work on both internal Win server and on Azure.Our Client wants to check out Azure but maybe later he will want this app to be on its own on premise servers. Our Developers are almost all .NET back ends, with basic knowledge in HTML 5, Javascript, Jquery, and bootstrap. We accepted the challenge because the project is tiny and interesting, the point is, is possible to have 1 project that can be deployed to azure or IIS with no problem? and what kind of project should we create? I think that a simple asp.net project with some web methods and js will do the job, but I don't know if it will work on azure too. Back n 2010 I did something that way but now I am not sure it's still valid
Important: the web application should be able to query oracle on premise server, via web service but not sure if take azure service bus or azure vpn
It depends on how you build your application. I have built applications in the past that works both on-premise and on Azure. As long as you don't access any Azure specific features, there's no problem to deploying the web application project to an on-premise IIS.
If you use Azure-specific features or services from Azure, such as Azure SQL DB, you have to built an on-premise version. In my case it was simple as changing the connection string and the rest was done by Entity Framework, but you can use an IoC container, such as Unity, to change your implementation based on the environment you're running on. If the Azure environment is available (check through RoleEnvironment.IsAvailable) you resolve the Azure-specific implementation of some features and if not the on-premise implementation. In most cases that are just a few dependencies, for example if you use a worker role on Azure and a Windows Service on-premise.
Need an advice on design approach. I spent couple of hours googling and still cannot come to a conclusion. Task at hand:
design intranet app that will have access control. Users should be given rights to access it.
C# is a preferred design language
app can be a simple form with some text fields and some fields as dropdown boxes from a DB
app will send SOAP request upon form completion
there should be a couple more forms like db search, preferably with sorting ability for columns
There is a Sharepoint I can get access to. Can it easily solve the access rights management or or should create a separate app on the same IIS or perhaps I shold request a separate IIS created and deal with access rights via DOTNET solutions? What is the quickest way to design this in your view?
Our SharePoint is 2010, and professional edition of VS2013 available for development.
Thank you
About SharePoint:
There is a permission management in SharePoint. You can set user permissions up to individual items, files and pages. You can read about it here: User permissions and permission levels in SharePoint 2013 and here: Fine-grained permission reference for SharePoint Server 2013. You can use differend authentication providers (AD, FBA, Oauth etc): Authentication, authorization, and security in SharePoint 2013.
You can create customization declaratively (no code), ะก# or javascript. There is built in object model (client and server) and web services (REST for 2013 or SOAP for 2010). More about SharePoint for developers
You can use built in form web parts or create custom with server code (C#) or with just HTML and javascript. All you can do with asp.net - you can do in SharePoint with custom web parts. But you can do most of things just with HTML and javascript.
You can request web services from server code (C#) or from javascript - just like in asp.net apps.
You can do db search with javascript or server code, using your prefer datagrid controls.
I think most easy way is using SharePoint 2013 Foundation (it's free if you have Windows Server license). And using javascript and HTML - in this way you don't need to know anything about deploying solutions in SharePoint etc. But you can do it via custom web parts - in this way you may do it like common asp.net development. But it's not a best way.
I have a requirement that I need to be able to have a stand-alone version of application, as well as an online version. One possible way of doing this would be to have a WPF version, which would satisfy stand-alone, and an MVC Web version.
Obviously, that would require two code bases (though admittedly they should be identical except the front end code). Is Web API self-hosting stable enough that I could just host a full-blown web app inside of it if I needed to?
Web API can run selfhosted but for running ASP.NET (MVC) you require a server like IIS (Express).
What you can do is have IIS Express installed on a machine, host your Web app in that and have Web API self hosted if needed. Of course if you already have IIS Express installed you might simply want to opt to run everything in it: both Web app and Web API.
Provided you're ok with using both internal/external apps using the same database/service you could host a single version of the WebAPI server in IIS, and simply use it for API Controllers.
You could then use two identical ASP.Net MVC sites (rather than Desktop & Web), which make calls into your WebAPI service. One hosted on the intranet, one on the internet - both hitting your WebAPI for business functionality & data persistance.
The goal here is to reduce the amount of code maintained. Essentially, it's two projects - your WebAPI project, and an ASP.Net MVC site.
I use Web API for self-hosting a number of projects that are in production. The web site http://www.hypermediaapi.com is a self hosted Web API.
No need to have two or more code bases for this scenario. What you need is a library what provides the API for your applications. The library can be used directly in the standalone application what I assume is a desktop app.
You can then create a WCF or Web API or even both layer what isn't anything more than a wrapper around the same library. The WCF/Web API contracts can be the same as your DTOs so the WCF service implementation would be something like this:
SomeObject IMyService.DoStuff(string param)
{
var myLibrary = new MyLibrary();
var someObject = myLibrary.DoStuff(param);
return someObject;
}
The only overhead would be that when an interface changes in library the changes have to be repeated in service interfaces too, but no actual business logic would be duplicated.
You can even share the interfaces, i.e. the API would expose the same interfaces what are implemented by the WCF service if you don't mind having the contract attributes on library interfaces.
I would like to upload some files on a server Share Point.
My questions are:
1) I started developing my project as a Windows Service but I read several parts of this WebService. It's mandatory that it's be a WebService?
2) I added the references to. Dll take it from my SharePoint Server (as seen in most discussions) but a little read more shares can not be tested if not solely on where you installed SharePoint Server. Right or there are alternative methods to do this? And also, when we deliver the service, can I install the latter on a machine where SharePoint is not installed (it seems a trivial question, but it seems strange not being able to test
but you install it).
You can only reference SharePoint 2007 assemblies from code that is running on the machine where SharePoint is installed (if you were using SharePoint 2010, you could take advantage of the Client Object Model).
Only the part of your solution that is directly interacting with SharePoint has to be created as a web service. You should create a web service with basic methods like UploadFileToLibrary, deploy it to SharePoint machine and then call these methods from the client (it can be an ASP.NET page or desktop application).
As Kit Menke pointed out in a comment below, it is possible that built-in SharePoint web services will be sufficient for you needs and you won't have to create a custom one:
Upload a file to SharePoint through the built-in web services
Copy.CopyIntoItems method