I am developing a Net Suite application based on web services (SuiteTalk). I have learned about the concept of System Notes, which are a journal of changes on all types of objects. Yet, I see no way to access the list of system notes (say last N notes) via web services. Are you aware if this is possible and how? If not, what would be an alternative solution?
I know you can do it via a RESTlet/Suitelet, not sure about web services.
In JS you can do a search with a joint field on the results.. something like :
nlobjSearchColumn( 'date','systemnotes');
*I think is systemnotes.
Do the filter criteria on a UI search, and link that search to the service script, from there is pretty standard.
Related
A client's employee base is struggling with using sharepoint UI as an interface. As a result the client is evaluating the option of building a custom UI on top of sharepoint to provide a better user experience; [The other option being to move away completely from sharepoint (non trivial, high cost option)]
My research indicates that you can customize the UI look and feel (but the client is looking for much more).
Another option appears to be to change/improve the experience by building PowerApps
The option I have been trying to assess,is to see if sharepoint provides adequate set of APIs/integration interfaces that allows the user to build a completely independent UI and user experience. Its effort intensive ofcourse, and feels like reinventing the wheel, and am wondering about whether others have faced similar UX callenges, and what possible solutions they might have evaluated, and path they have gone ahead with.
Under the covers, SharePoint is a SQL database and a collection of .NET classes that define each SharePoint object: SPWeb, SPSite, SPWeb, SPList, SPUser list item, document etc. Most of these objects are exposed via web services. Microsoft then built an IIS/ASP.NET based UI for the out of box user experience. There are mobile apps that are not browser based that call the SharePoint REST services to read and update lists and libraries. If you wanted to, you could built your own complete UI based on just about any technology. Is it worth it? Probably not. There are many customization options available, depending on your version of SharePoint.
(If I could post comments... :-) I would then ask: Tell us more about what the users need in the UI that is not supplied by out of the box SharePoint.)
This could have been already discussed but in context of Dynamics CRM 2013, I am wondering what is the recommended and easiest approach (mine is a on-premise deployment) :
Problem :
May be a known pain point with 2013 - Users want to see 'All Activities' of a Company and related Contacts, Child Companies but
excluding few activities (like campaign emails).
Solution :
Thinking to create a custom form or a web resource which can use CRM web services to query for this data and make it part of the Company form.
Question is :
What is an easy way to do a custom page where I can use CRM web
services to query for all activities data and filter campaign
emails and display it like a grid ? I see two options :
Develop a separate aspx web application(using SDK binaries as references and crm web services) and host that outside of CRM (in IIS) and
use that url in an IFrame within company form.
Develop this as a html webresource (with a grid) and somehow make crm web services call from java script and display as a web resource (If so, is this
easy in CRM 2013, since web api is only present in 2016 ?)
Or something else ? (like a SSRS report may be but I think it will
be too slow)
Many thanks for your advise on this.
Thank you.
I work for an organization where most of the times requirements is like yours, so i have already done a separate aspx web application like your option 1.
Following are the few things to keep in mind:
If you go with Option 1 and develop a custom aspx web application and host it in IIS, it will be alot easier to maintain in future and easy to customize based on new requirements. If you have any new requirements like this in future, it will be easy to add a new aspx WebForm to the existing site and refer that new url. You can have common classes for Connection and authentication stuff in your web-application, which is almost re-usable.
I have used the same approach as described here: Best Practices for Working with Custom ASP.NET Pages and Microsoft Dynamics CRM 2011
In case of Option 2, i have tried this once but it is a bit more complex than the Option 1 because it involves more JavaScript code than C#. It is difficult to maintain although will be a bit-fast than the Custom Web App, but not re-usable code in case new requirements. Also Queries in C# (QueryExpression) is way more easy to write than writing Odata Queries in JavaScript.
Thanks.
I don't know about SharePoint that much, so hope that someone can give me some good explanations for me.
For SharePoint application, we don't need to consider SharePoint DB design? Everything is done through List and SharePoint will take care of the Database? Don't need to consider it at all unless we are connecting to the external Database?
For Parent Child relationship, I have to use lookup field?
If we are developing using Web parts, we need to deploy it using Features. So eventually, there can be so many features in the production? Is it recommended in this way?
1)
For SharePoint application, we don't need to consider SharePoint DB
design ? Everything is done through List and SharePoint will take care
of the Database ? Don't need to consider it at all unless we are
connecting to the external Database ?
You do need to consider the database... In term of administration. back ups, restore, size and so on.
however you never directly read or write to it. You don't need to pay attention to the schema because you won't ever be directly using it. If you want to update something in SharePoint you do it pragmatically with c# / vb.net using the SharePoint API's. You have 2 API's one that works on the server called the SharePoint object model and one that works on a remote machine called the client side object model.
From a users perspective, you are correct lists contain data in SharePoint and are somewhat smiler to DB tables in some ways.
2)
For Parent Child relationship, I have to use lookup field ?
Yip
3)
If we are developing using Web parts, we need to deploy it using
Features. So eventually, there can be so many features in the
production ? Is it recommended in this way?
This can happen if you create a new solution for every web part but you can bundle multiple web parts in the same solution in the same project in the same feature
Right click on your project --> add new item. select a web part. By default the web parts will all be part of the same feature but you can separate them out and have multiple features in the same solution if you want to
I need to programatically interface with SharePoint folders, files and lists from outside SharePoint. Most tutorials focus on working within SharePoint itself, or at least on the same server where SharePoint is installed. I need to automate some tasks from completely different servers -- tasks that require reading SharePoint lists, browsing folders, checking files out and in, reading files stored in SharePoint libraries, etc. It used to be easy using UNC folder and file paths. Now many of our SharePoint sites don't allow UNC access (probably for good reasons), but my needs are the same. What languages / libraries / interfaces will allow this? I'd like to be able to do this from server-side .NET code and from PowerShell scripts (not on the SharePoint server). Thanks for any pointers.
SharePoint offers a web services API. I won't claim it's particularly friendly or fun, but it does work. You can get started learning here.
Use Sharepoint Web Services which provides a suite of standard web service endpoints you can use to do most anything you can through the objet model API.
You can use SPServices whichis a jQuery library which abstracts SharePoint's Web Services and makes them easier to use. It also includes functions which use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.
Here's anoth example of SPServices in use Example
if you are using SharePoint 2010 you can use the Client Side Object Model (http://msdn.microsoft.com/en-us/library/ee537247(v=office.14).aspx). It will help you to access sharepoint objects, lists and everything. There are 3 types one for C#, Silverlight and Javascript.
there are more than one methods:
use csom (client side object model)
use rest services
use sharepoint out of the box web services.
If you want to be able to choose the language in which you program, I'd recommend using the Sharepoint REST API. I'm writing my service in Java, requesting data in JSON, and using Jackson to parse it into Java Objects.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.