I'm a Sitecore beginner, working on Sitecore 8 with ASP.NET.
There is a page where an Ajax call has to be made to get data.
Created a test web service in the project which responds to the ajax call with success. This service will be a wrapper.
I understand, I have to consume one of the 3 options (in the title) inside the test service, to get the Sitecore items and do stuff.
But all 3 appear similar to me & not sure which one to go with, to achieve my task
Also,
1. Is there an advantage of one over the other.
2. ..and when to use which one.
Sitecore Services Client is the framework or namespace that both Item Service and Entity Service sit within. Item Web API is the legacy framework.
Use Item service if you want to do basic stuff with the sitecore Items as this is a prebuilt api. Entity Service allows you to create your own API using the Sitecore.Services.Client framework and give you much more power and control.
https://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Use can also use Sitecore.Services.Client to do the routing and you write the controller. see https://mikerobbins.co.uk/2015/06/25/sitecore-service-client-servicesapicontroller/
Related
I have a requirement to build a service endpoint to provide specific Sitecore 8.0 items (containing a given field value in a given branch of the content tree) to requesting mobile app clients. Encapsulating this logic (and perhaps some other calculations, etc) means the out-of-the-box API is not suitable.
I'd like to mimic an existing SOAP service exposed by another CMS, however I'm not above using a modified version of the RESTful itemWebApi if it confers greater code reusability or upgrade-safety.
Based on my research thusfar, it would appear my options are to build a custom handler, a completely separate asmx service (ala this approach), or to build a custom controller (similar to this custom Web API controller method).
Overriding or replacing the default pipeline processors for the itemWebApi does not seem viable, as I don't want to replace/modify the OOB API if I can avoid it.
Has anyone with the same type of requirement for Sitecore 8 found a better approach?
The approach I chose was to create a separate service "router" developed using the adapter pattern to be consumed by our mobile app clients. The router in turn calls the Sitecore ItemWebApi.
This fit my needs the best as it is completely decoupled from the Sitecore application and the client can be modified if necessary without impacting the endpoint.
It would also be worth looking to EntityService within Sitecore.Services.Client in Sitecore 8. Its a Web API based service but has more flexibility over the standard Sitecore Item Web API because you can define your model and the business logic yourself.
I can see you have mention my other blog post on adding a custom Web API controller. Enitity Service is different, it's a framework by Sitecore to achieve a standard way of creating custom web service for Sitecore.
I have written a blog post on EntityService. It has both a Javascript and standard rest based API to communicate with the service too.
http://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Example Application here: https://github.com/sobek1985/EntityServiceDemo
And a few more posts on advanced features in Entity Service: http://mikerobbins.co.uk/category/sitecore/sitecore-service-client/
I am researching how to integrate Microsoft Dynamics NAV with my existing REST API (built on Django REST Framework). What I would like to do is trigger API calls from NAV to CRUD objects via the REST API.
Reading the web services docs for NAV, it seems clear that NAV can expose a web service for other software to consume from. But can NAV consume 3rd party APIs? In the web services examples documentation, it says:
Solutions that need to execute business logic or read data from
Microsoft Dynamics NAV are candidates for Web service implementation.
These can also be solutions that write data to Microsoft Dynamics NAV
and validate the data using existing business logic.
Also, it gives the following example of how to use web services:
Execute any kind of business logic that is more easily developed and
managed in Microsoft Dynamics NAV.
However, I don't see any examples of data writing. It doesn't seem that in the exposure of web service pages or codeunits, there's a way to make calls to 3rd party APIs and execute business logic with the data that comes back within NAV. Is this actually possible?
Unfortunately not, no.
You do however have access to the full .NET framework from within the 'Development Client' of Dynamics NAV - When defining your variables select the Type of DotNet
It's far from perfect, so for larger tasks I'll create AddIns or completely external libraries (depending on version).
For something smaller like this I personally find it easiest to write it in C# as a small (console) app and the 'translate' it back into Dynamics NAV.
If you are looking for way to invoke a web service then why do you need Nav web services? Nav web services is a way to call Nav.
These can also be solutions that write data to Microsoft Dynamics NAV and validate the data using existing business logic.
This means if you invoke published Nav web service then you can pass data to your call and the data will be validated and saved to Nav. So this is about how to push data to Nav, not pull from external system.
If you want to invoke a web service from Nav consider this options:
Write external wraper library (as mentioned by #SeeSharp or as described). Then use it in C/AL as DotNet or Automation types of variables.
Use existing libraries like 'Microsoft XML, v6.0'.XMLHTTP60 right in C/AL to make http calls to your web service.
Do it Navision style.
Last damn option is to write console application that will consume your web service and call it from Nav using shell. This is not an option, I know.
I am not sure if I am comparing onion with a cabbage. But I am really confused with the portlet and a web service. I know that web service is making your software components in your application as a service to other applications but to me it is similar to a portlet responding to requests. I know that my understanding is making you(Portlet & SAAS developers) really upset. But I need some clarity on this.
Why cannot I use the request-response to portlet work similar to a web service?
If yes, what is the benefit I get in using a web service than a portlet?
If not, then what are portlets lacking to act as a web service?
I am a newbie in portlet development. Please dont curse me for this question.
Please suggest.
EDIT:
Most of the answer say that the portlet is a UI component. My customer has requested me to create a webservice in liferay. So is it to make a portlet as a web service? If yes, can you please provide a pointer or some code snippet?
Addressing your 'edit' specifically with regards to Liferay...
Liferay plugin projects can expose web services without too much work.
The Liferay Service Builder actually has facilities so you can create SOAP web services or JSON web services backed by tables in the Liferay database (and that make queries on existing database tables). In the case of JSON web services, the URL scheme generated is not RESTful (unfortunately), but it is well defined. With a bit of work on your part you can impose Liferay's permission system on web service calls as well.
Here's a reasonable starting point in the Liferay Developer's Guide:
See the links on that page to SOAP and JSON services.
Note that a 'portlet' is only one type of Liferay plugin. The web service facility is part of the service layer - which can be used by many plugin types. So there isn't necessarily a portlet involved in creating a web service in Liferay, you can make a web service that has no visual component associated with it.
Portlets are areas you create to add and display content. Portlets can be added to the left and right of the center body area and can contain myriad content ranging from news, events, calendars, RSS feeds, collections, plain text, and more. Also, you can set properties and policies for showing the portlets.
you want to use portlet when
You have content you want to have special focus, like news.
You need to specify the configuration data for an item. - i.e. number of entries to show.
You want to give the content editors a choice about when and where to display content.
You'd like to show it only to some groups or users.
On the other hand, web services:
Enables applications to expose their services
“progammatically”, i.e. the services can be invoked by programs
Enables software running on other computers (could be a desktop, mobile phone, PDA, etc.) to invoke operations exposed by Web applications
if you are trying to identify the main difference portal historically, the portlets have three layers architechture (client, middle tier, backend) this cause two weakness:
Different portal groups have no well established way of sharing services
Different technologies(Java, Perl, CORBA, EJB) in middle tier.
Different protocols(GRAM, IIOP,...)
Consequently, lots of redundancy, reinvention
Example: batch script generation
so Web services address the service sharing problem and reduces the redundancy.
source1 source2 source3
Portlets are meant to be a user interface component in a portal solution.
Web Services provide functionality to remotely interact with a system commonly using SOAP, REST, JMS or other related
They provide completely separate functions. The closest you get is the serveResource method in portlets. This functionality is used to serve various types of content from a portlet (such as a PDF document or an AJAX response) without the need to perform a full page request.
I am very new to SharePoint development as well as SharePoint overall, so I apologize if this question seems like a no-brainer. I'm currently working on a SharePoint 2013 app and I'm wondering if it's possible to make a call out to some URL from within the SharePoint environment. Basically, I want to do this within an event receiver after some action is done to a list, and from there I want to make a call to some web service on my server to update my system. Using the REST API to poll the SharePoint server isn't a good option for this scenario since it won't scale very well.
When dealing with SharePoint 2013 apps you can access any resource using standardized APIs. In addition to REST SharePoint is offering the JS Client Object Model (CSOM).
In order to access data from another web than the current one, your app needs the permission to interact with the entire tenant.
If you're trying to query data from another host, you have to use JSONP because of the same origin policy.
if you are building an app using the "new App Model" for wiring up Remote Event Receivers it is possible to do anything, in which your app hosting framework/environment allows you to. If you are building a Classic App (Farm Solutions) you'll have access to perform operations which are allowable from the SharePoint servers directly...typically this is a lot as GAC deployed assemblies are granted full trust.
depending on what you are trying to do and what kind of resources you app will consume. I'd consider moving the dependancies away from SharePoint and building using the new App Model versus the older farm solutions. As you sound like you are starting in SharePoint, this gives you an opportunity to learn the new ways of doing development for SharePoint.
Lastly, you might consider building a workflow. Not sure what kind of app you are building but the new workflow capabilities include actions which can make RESTful calls. Potentially making your application a "no code" solution. Again it all really depends.
So here is the scenario:
I have a MOSS 2007 box and I want my clients to be able to access a SharePoint site via the internet. I am told that I will be using an IPA and AD for authentication. However I have a DB outside of SharePoint that holds various business data and I want to use Web Services to access the data, manipulate it, and send it back to SharePoint via web parts.
The issue is that, from what I understand, I am going to have to authenticate the AD user every time a request to the Web Service happens. Obviously I dont want to do this every time because they have already authenticated to get onto the site, however I do want each call to have some form of security so its not open calls to my db. I do plan on having other applications access this service outside of SharePoint, so I dont want to have to reinstall the service for each application or even again.
Has anyone had to perform this task or something similar or do you have any suggestions on how to do this?
Thank you in advance and happy coding!
Why not just deploy the webservice to Sharepoint using a Sharepoint solution and a Feature.
That way it will be running under the sharepoint app pool and all authentication is done by sp.
Edit:
Seeing that SharePoint should not be in "control" (as stated in the comment), you should create the webservice, and run the application it's under in as using Windows Authentication. IMHO you should create a WCF Service. The, using the information found in this article you make the Service authenticate users against the AD usergroups they are in. see the "Security: Authentication" section of the article.
Then in Visual Studio you create a webpart and add a service reference to the project, pointing to your newly created Service. Have the webpart perform the needed logic (i.e. display data etc.)
Deploy the webpart to SharePoint using a SharePoint solution (.wsp files, created with WSPBuilder). Google for SharePoint + wspbuilder + tutorials. The solution should contain 1 feature to deploy the webpart. WSPBuilder integrates with VS and allows for the creation of WSPBuilde project. add a webpart feature item to the project (it will create the xml (deployment related) and code file for the webpart.