Looking for somewhere that describes the differences between the SharePoint 2013 APIs, specifically I'm wondering what APIs I can use to create databases and site collections. As far as I can tell, only the Server API or Powershell will let me do that. I was hoping I could be proved wrong and be able to use the client object model or the REST services. Anyone know for sure?
No only server-side OM offers these kind of operations. Both CSOM and REST are built to deal with data and services hosted within SharePoint.
Here is an MSDN article which best describes what you are looking for:
http://msdn.microsoft.com/en-us/library/sharepoint/jj164060.aspx
The largest set of APIs is in the server object model of managed
classes. At the level of SharePoint Foundation 2013, this object model
includes classes and members that enable programmatic control of the
basic site and list structure of SharePoint Foundation. Most of these
classes are in the Microsoft.SharePoint namespace. In addition, you
can extend almost every SharePoint Foundation component by using the
server object model, including workflows, alerts, Web Parts, basic
search, and Microsoft Business Connectivity Services (BCS). The server
object model also includes an extensive set of APIs enable extensions
of the administration and security system of SharePoint Foundation,
including backup, farm health and diagnostics, logging, farm and web
application management, upgrade, deployment, caching, and Windows
PowerShell customization.
The highlighted part is not available in other API.
Related
I am having a bit of an issue with integrating with NetSuite API on .Net Core using VS2017 and it has no option to add Web Service. When I consumed their web service using add connected services some objects and classes are missing.
In .Net 4.5, the classes and object are available. My manager wants me to write the API in .Net Core.
I took the sample code from NetSuite and the very first thing is class NetSuiteService which has important Passport property for login.
Anyone had a solution to this?
It's fairly easy to integrate SuiteTalk with Dot NetCore, all you need to do is import the WSDL into .NetCore project via adding it as ConnectedService reference and it will set you up with WCF.
The DEMO code that NetSuite people have provided will not match the code generated on your machine. I would recommend you using TBA instead of other authentications.
(just copy paste the code provided by NetSuite's folks for authentication as that is the convention, you can change the crypt algorithm if you want to, just generate the Keys, put them in your configs and you're good to go)
Class "NetSuitePortTypeClient" will contain your endpoints for all types of communication to NetSuite web services.
Read the first 50-100 pages of the documentation manual that NetSuite provides for learning the conventions to be used throughout your journey.
Hope this will give you a headstart.
I am looking into options for implementing single sign-on (by which I mean a single set of user credentials authenticating against a single, shared, identity store) across a range of websites.
All of the websites nominally belong the same organisation (and so we can assume a trusted relationship between them), but are hosted on different domains, and span different technologies - inc. .NET, Java and PHP.
We are consolidating all user profiles into a single back-end CRM system, and need some way to provide robust access to this for all current (and future) web properties.
We have a nascent SAML provider running, and the default option is to extend access to this across all the (currently) unsupported properties. Is this the best option? All the online references to SSO products (CAS, CoSign etc.) seem to be very old (2004+).
Have a look at Microsoft's ADFS v2.0 which support .NET
There are commercial products that do this e.g. PingIdentity, and open source ones e.g. OpenAM.
These products all support SAML.
For Java, put something like OpenAM in front of it or use the OpenSSO / OpenAM fedlet.
For PHP, use simpleSAMLphp.
The keyword to use to get current references would be something "SAML federation".
Refer SAML-based products and services
Use of the SAML protocol here makes a ton of sense. It could even allow you to federate with cloud-based services if/when your company decides to go that direction.
SAML does not require the target servers (aka "service providers" or "relying parties" in MS parlance) to be referenced using a fully qualified domain name with a common DNS root. It is also technology agnostic so it really doesn't matter what HTTP stack the service provider is running.
I'm not sure what interfaces are available to your back-end CRM system, but LDAP or SQL connections are typically used to get identity claim information and build the SAML response.
A few Identity Provider products you may want to research include Microsoft ADFS, PortalGuard (for whom I work) and Ping.
I am evaluating WSO2 for our SOA governance solution. Few questions
It provides a way to document services. Is there a way to document each operations listed in WSDL or resources of a RESTful service? I am not able to find this information.
How do I provide information about RESTful services?
Is there a policy enforcement?
Thanks for all the responses. I did look at API manager. Looks good but have couple of questions
I couldn't find a way to document endpoints for various environments. only 2 URLs supported - for sandbox and for production. How can I provide url for more environments?
Is it possible to customize lifecycle?
and 2. You can define your own metadata this means you can store any data (the new data types are defined via XMLs which you upload to the server), there is a tutorial by the wso2 team with an example on how to do that.
I'm afraid I don't get what you mean in 3. Do you want different users to be able to create different type of artifacts?
This is a tutorial I've found useful: http://www.youtube.com/watch?v=pXfxiZlOtH0
You can also find documentation on the wso2 website
To me it sounds like you might want to have a look at Wso2 API Manager 1.0, in fact it provides a nice interface to write your documentation for APIs in the 'publisher' side.
Also you will have all the information the user needs to consume the Restful Service + an API key to Authenticate in the 'store' side of the API Manager.
You will not have to worry about G-Reg because the API manager already include one and allows you to easily govern your SOA services.
Hope this helps
In SOA deployment, you can use WSO2 ESB as the PEP (Policy Enforcement Point).
Please follow this article for more details. In that kind of deployment you can use mounted WSO2 Governance Registry server as a policy store. That will facilitate you to maintain the service policies in central repository and governance capabilities like Versioning, Life cycle management, Notifications...etc.
I am going to create a basic "CRUD" application that will "live" inside Sharepoint 2010. The data will be hosted on a SQL 2008 R2 Server.
Basically, there will be a few "Add" forms, some Queries and some Reporting (SSRS).
Honestly, the application doesn't really even need Sharepoint, but we are trying to get as many of these applications hosted inside Sharepoint as possible. (The application is currently a Microsoft Access application.)
I have experience creating these types of applications (ASP .Net) and have recently been using the Entity Framework. Generally, I design my Data Layer in a seperate Visual Studio Project (using EF) and then extendthe partial classes it creates and/or sometimes create another POCO layer to access the data (depending on how much "business logic" there is).
Anyway, the question I have is:
If I create a (Visual Studio) Solution (I know I have to target .Net 3.5, since because SP doesn't support 4.0 yet), can I use my usual "layered" design and create a seperate project (assembly) that conaints all of my Data Access (Entity Framework) and then have a seperate Project that contains all of the Visual Web Parts (that we design the Data Entry Forms in)? Will this work? Will I be able to call the exposed methods from the (EF) DAL from within the Visual Web Parts (after I deploy my solution to the SP Server)? Will I have to do anything "special" or will both projects get packaged up into a (what is it) "wsp" file and get deployed to SP? (Or, will I have to manually get my DAL Assembly added to the GAC, etc.)
Any examples or tutorials would be a big help to me too.
Also, if you think I am going about this all wrong, I am also interested in knowing how you would create a similar appliation. Is there a better way to do this? (I know I could create a BDC Model and access our SQL data via a Sharepoint List using the External Content Type. Although, for some reason it just seems like that isn't the "right path" for this particular application... I can't put my finger on it, but I am leaning toward just creating a "traditional" ASP .Net app that just uses SharePoint as its "hosting web server".)
Thanks!
Shayne
Can you do it: yes. Should you do it: probably not.
You hit it on the head. You are creating and ASP.NET application, not a SharePoint application.
Anyway, assuming you are going to have to proceed in this manner, here's my advice.
Build the presentation layer (web parts, application pages) using the SharePoint project template and SharePoint project items. This project can reference the assemblies that implement the remaining layers of your application. Visual Studio will then prepare a Solution Package (WSP) that can be used in testing and deployed to production servers.
You should do everything you can to make your application "fit" into SharePoint. It should use the same UI metaphors, respect branding, and so on. Nothing is more jarring to a user then to have pages and web parts that look and behave total different to SharePoint in the middle of a SharePoint site.
If you have the full version of sharepoint you can use Access Services, which will convert your Access application to a web app, just run the wizard
see this video for details: http://channel9.msdn.com/Shows/Access/Microsoft-Access-2010-Demo
Greetings!
I've spent some time researching how to communicate with SAP from a PHP web application, but the documentation is more than spare. The ways I found are:
Creating IDoc files, some sort of proprietary plain-text format. But how do I stick them in SAP when they are created on the webserver?
Coding a Windows Application using the SAP BAPI. This way, you have full control and access - but also a lot of pain.
Accessing the RFC (Remote Function Calls), preferrably via SOAP. This would be the best way to connect to a web app.
What I could not find out is: what is the easiest way to connect? Which versions of SAP support SOAP? Anything I've missed?
Thanks for your help!
How you connect to SAP is dependent on what version of SAP, your SAP license and what you're connecting with and what you are trying to do.
If you are trying to access SAP standard functionality - i.e. Read or Update a SAP Service Order, the standard BAPI should allow you to do what you need. (Note that a BAPI is just an RFC with a standard API, which is released for customer use by SAP).
There are various connectors to SAP, but for newer releases of SAP (2004s and later) many RFC function modules are exposed as webservices, which should be ideal for your purposes.
You may have to ask an ABAP developer (or even a non-developer with SAP experience) to help you find which RFC's are available and whether they are exposed as webservices. (If not an ABAP developer should be able to wrap BAPI as a webservice with a simplified interface).
If you are trying to do something that SAP have not provided prior functionality for, or perhaps access custom developed objects you will definitely need the assistance of an ABAP developer to exposes an RFC to you.
Depending on your system setup there may be some system administration tasks to be done in order to allow you to access the SAP system. Whether by RFC or otherwise. (Useful transactions to search for are SICF and SOAMANAGER). The SAP Basis administrator may also need to set up some RFC connections for you.
If your company uses SAP PI/XI or a non-SAP integration engine, it may be easier to connect but that would be in very limited cases.
I've used IDOCs before for single message transfer, but I'm not sure that it would have any advantage over BAPI's or webservices for any Business Type transactions. Although IDOCs have been around for a while and may be quite stable if standard ones exist.
I have to admit that I've only scratched the surface around connecting to SAP, but I hope this is useful.
The third option is the easiest.
Accessing the RFC (Remote Function
Calls), preferrably via SOAP.