We are creating an application in C# that uses CMIS to query remote repositories (Sharepoint, alfresco, etc.). My colleague set up the service references and we're able to connect and retrieve basic information. My part is to implement searching using the DiscoveryService.query. The issue is that the service that was represented in C# doesn't match the service documentation (found at http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html#_Toc243905469).
Apparently when generating the service, an additional parameter is added at the end of the parameter string (XmlAttribute[] anyAttr) for DiscoveryServicePortClient.query.
I've searched high and low over the web and can't find a single instance of this issue.
Have you been successful in integrating CMIS w/ C# and searching the remote repository? If so, how did you create your service references and what did you pass in as your parameters? Any assistance would be greatly appreciated as not only is my head hurting, but there's a huge hole in the wall where I've been banging it for the past two days. (If there's add'l information needed, just ask and I'll add it to this post.)
Apache Chemistry DotCMIS is a .Net client library for CMIS.
If you don't want use it, you can at least have a look at the source code.
Related
I'm calling Dynamics 365 through it's OData Web Api and I'm wondering which client library I could use to make programming easier.
My use case is that I mainly have to work with one entity: contact. I would like to retrieve some data, edit data and create new contacts. The other entity type I'm working with in a similar way is address. A contact can have multiple addresses.
Currenlty I'm using plain HTTP Client class for the communication to Dynamics.
I am developing a .NET Core application for Linux hosts, because of this I can't use the Dynamics CRM SDK (SOAP Endpoint).
My question would be what your advice is: should I use Microsoft.OData.Client or Simple.OData.Client? Or any other library?
I tried to use Microsoft.OData.Client and generated a client (proxy/wrapper) according to this article: https://blogs.msdn.microsoft.com/odatateam/2014/03/11/tutorial-sample-how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class/
The problem with this is that it generates a .cs filewith 86 MB file size. Maybe it could be a solution to use this client afterwards, but it just seems so wrong to have such a big source file in our project. I would like to avoid it, but I didn't find an option to generate this If I accidentally open it, Visual Studio crashes, intellisense get's slow some times, if ReSharper is turned on VS is slowed down enourmously, etc...
I checked Simple.OData.Client and seems to have nice documentation and API. For instance: https://github.com/object/Simple.OData.Client/wiki/Retrieving-data
For Microsoft.OData.Client I didn't find documentation how to use it in a typed manner without generating the whole client. Is that possible? I only found this, where the generated context is used: http://odata.github.io/odata.net/v6/#04-01-basic-crud-operations
I think going with Simple.OData.Client seems to be a better option, but I would prefer to use a Microsoft library.
Do you have any reccomendations?
I have just implemented integration from .Net Core Web App running in Azure App services to Dynamics 365 Web API as a POC.
This included reading reference data ( joining different entities ) and modifying entities with referential data columns.
Full OData interface generation is problematic I found:
Could not find tooling that supports OAuth2 authorization and VS2019
Full interface definition inclusive of navigational properties / functions / actions and all entities with all fields becomes unwieldy to navigate and VS navigation is sluggish.
Depending on OData client you are going to use it will be sending much more information over the wire than needed and add complexity that is not in the spirit of the underlying REST OData service.
Generated code tools violated C# coding rules ( using reserved keywords like event, abstract and also generating members with same name as enclosing type ) requiring manual correction.
After much research I started using Simple.OData.Client as this allowed me
VS2019 / .Net core compatible toolset / runtime
Connect to Dynamics 365 OData Web API with OAuth2 bearer token
Write typed code in VS
Create only the entity models / navigational properties etc that I needed
Can select only the entity attributes you need to return instead of 200 ( smaller payloads )
You have to create the entity classes used in the typed fluent API yourself
Use DataContract attributes in case you want the CRM entity names to be different between CRM / C# code.
Simple.OData will then use the DataContract attributes when making up the Http call.
Unfortunately I didn't find the documentation all that insightful when I started looking deeper on issues like OAuth2 authorization and navigational properties but did find all my answers in secondary sources like github issues and some advanced tutorials for example
https://www.odata.org/blog/advanced-odata-tutorial-with-simple-odata-client/
Also using Fiddler to see the communications going back and forth is unbelievably useful in understanding what is going on.
Microsoft has introduced a Web API, a RESTful web service you can use to interact with data in Dynamics 365 using a wide variety of platforms, programming languages, and devices.
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/perform-operations-web-api
This is a new way of communicating with Dynamics 365 programmatically.
There are several libraries available that you can use. From below article, you can find those.
https://community.dynamics.com/crm/b/briteglobalsolutions/archive/2017/10/22/webapi-library-comparison-in-dynamics-365
I have personally used David Yack's library.
https://github.com/davidyack
Hope this helps.
I am struggling to find a way to simply use a OData v3.0 service in any way from within Visual Studio 2017, so I can use the Client library to help develop my app/service to consume the data.
According to the Microsoft OData Stack page, they seem to have all of the tools and support to consume an OData v4.0 service. Not knowing I was in fact dealing with a v3.0 service, I followed these instructions and as the page describes, there are two tooling options to get you started. One is the OData Client Code Generator, and the other is the OData Connected Service extensions
After having to go thru some hoops to even get either one to work (see GitHub Issue for actually finding a version of the Client Code Generator that actually works with VS2017, and and trying a work around to get the OData Connected Service to work with a service that requires authentication, I finally realized I was working with an OData v3.0 response. So these tools couldn't help.
Now contradictory to what is actually mentioned on the OData Connected Service marketplace page, where is says "OData Connected Service for V1-V4", this did not work. If the OData service requires authentication, then I get this error dialog from trying to add a Connected Service via the extension:
So then I read in a GitHub issue (can't find it), is that a potential work around is to download the XML that is returned from hitting the /$metadata endpoint, rename it to whatever.edmx and try to use that for the extension by providing a file:// URI to that file. That didn't work with the following error dialog:
So then I ditched that approach and tried to instead use the Client Code Generator, and providing the edmx file to that in the TT config (to solve the auth issues, and that didn't work because it was OData v3.0 and not 4.0.
So then, it seems for v3.0, the approach is to use Add Service Reference, but when I do that, I get the following error:
..but that tool doesn't support v3.0.. so now I have no idea how to proceed!?
Any help would be greatly appreciated!
Just in case someone else stumbles on this particular combination and can't seem to proceed with consuming an OData v3.0 service with current VS2017, (and specifically on how to use it in an Azure Function), here is what I did to get around this:
Reinstall VS2015 and create a new library project
Add a new Service Reference and point to your OData v3 (or earlier) service. if the service requires authentication, this dialog will allow you to enter the creds. I was prompted to enter them 2x.
Create a class / service / interface that will expose all of the relevant tables / queries that you are interested in consuming from that OData service
Save the project and close VS2015
Copy this project to your VS2017 solution. In my case, I had a solution containing an Azure Function.
Now call upon this new project/library to obtain the data.
This is the only way I could get this to work after many many hours of troubleshooting various limitations and workarounds of the current versions. Needless to say, I am quite disappointed in the current state of the tooling + VS2017's support for consuming older versions of OData.
I am using the SalesForce Partner API, not the Enterprise API. I want to be able to programatically (C#) add a custom field to any object in SalesForce (as an External ID) so I can merge data from external systems into the SalesForce object. I know there is a way to do this with the MetaData API, but I've also seen a number of references that suggest it's possible through the Partner API, which would be far better because we don't need to spin up yet another API connection to achieve this.
There seems to be no information about this anywhere. I can't find anything on the SalesForce.com help website or anywhere else on the internet and although mentioned in other posts, it doesn't appear that anybody has posted information about how to do it, or not that I can find anyway.
Can anybody point me in the right direction? Some sample code or a link to an article somewhere describing how to do it?
Thanks very much.
Since you need to create a custom field - which is metadata - only Metadata API can help you.
I am not sure what you mean by "to spin up yet another API connection" - but you can use Metadata API in the same service IMHO. Just get the Metadata WSDL and consume it. All your other calls with the partner api remain the same.
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_calls_intro.htm
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_quickstart_java_sample.htm
So I'm trying to find a "Best" way to interact(create a interface) with Active Directory read/write mode. So I'm deciding between this two aproaches:
Try and use the ADWS.
C# Implementation.
Apparently for ADWS is not that easy even though there is a full WSDL I'v not been able to locate it, to try to do some test via SOAPui...
Now fort the C# Implementation there are few implementations
but still I'm not sure if its 100% doable to have full READ/WRITE to AD i.e. creating accounts users, query for users info, etc. from lets say REST WS.
So My questions are
Is there a way of getting a WSDL from the AD server so that I can use that as a starting point? ( I don't want to get me into PowerShell stuff or the like)
Are there any good articles for the latest versions C# ,libs, etc... to help me implement this?
Is there a better way of doing this?
As an example This is what we're trying to do:
Scenario 1:
Create a Web Service (INTERFACE) that expose AD information
The Web Service could be REST or SOAP
The WS should read/Query/Write the AD
Any Application inside the network can consume the WS
Scenario 2 (What we currently plan to do):
Sharepoint Reads AD Information
Job should copy AD to DB
Applications can read this data
There should exist some replication between the DB and AD
Any suggestions will be more than welcome
I'm Using server 2008R2 ,Sharepoint foundations 2010
I'm assuming this is related to your previous question which mentioned Exchange.
My personal suggestion is to host a WCF service in IIS. You can set this service up to do whatever you want to suite your needs for the apps accessing it. You can probably do most of what you need to do through the System.DirectoryServices.AccountManagement namespace when it comes to User and Groups.
System.DirectoryServices will give you more granular control at the cost of more work. However, it is a little easier and reading and writing from/to custom attributes here.
If you're going to interact with Exchange 2010 you'll need to mess with Powershell. And you could use Powershell to do core AD work as well.
And of course if you're going to write your own web service you could make it REST.
Here is a link to MSDN with info about System.DirectoryServices and the various namespaces. I personally find AD to be a lot of fun to work with. There are many ways to do the same thing in it so I don't think there's one right answer for you. Go with what you're comfortable with or challenge yourself to do something new!
Following the KISS principle, I suddenly realised the following:
In .NET, you can use the Entity Model Framework to wrap around a database.
This model can be exposed as a web service through WCF.
This web service would have a very standardized definition.
A client application could be created which could consume any such RESTful web service.
I don't want to re-invent the wheel and it wouldn't surprise me if someone has already done this, so my question is simple: Has anyone already created a simple (desktop, not web) client application that can consume a RESTful service that's based on the Entity Framework and which will allow the user to read and write data directly to this service?
Otherwise, I'll just have to "invent" this myself. :-)Problem is, the database layer and RESTful service is already finished. The RESTful service will only stay in the project during it's development phase, since we can use the database-layer assembly directly from the web applications that are build around it. When the web application is deployed, the RESTful services are just kept out of the deployment.
But the database has a lot of data to manage over nearly 50 tables. When developing against a local database, we can have straight access to the database so I wouldn't need this tool for this. When it's deployed, the web application would be the only way to access the data so I could not use this tool. But we're also having a test phase where the database is stored on another system outside the local domain and this database is not available for developers. Only administrators have direct access to this database, making tests a bit more complex.
However, through the RESTful service, I can still access the data directly. Thus, when some test goes wrong, I can repair the data through this connection or just create a copy of the data for tests on my local system. There's plenty of other functionality and it's even possible to just open the URL to a table service straight in Excel or XMLSpy to see the contents. But when I want to write something back, I have to write special code to do just that. A generic tool that would allow me to access the data and modify it would be easier. Since it's a generic setup around the ADO.NET Data services, this should be reasonable easy too.
Thus, I can do it but hoped someone else has already done something similar. But it appears that there's no such tool made yet...
You are referring to ADO.Net Data Services. It basically creates an Entity Database Model and adds a REST frontend to the service using ASMX. There is a How To article availble from MSDN here on consuming the service using .Net. I have also done the same thing using the normally WebClient class in .Net in the past.
You can also look at the WCF REST Starter Kit if you want to roll your own based on Entity Framework. The starter kit also contains a handy new WebClient class that can be used to communicate with REST services.
Clarification
There is no prebuilt application client that I am aware off which will talk to these service, since they are pretty much accessing the data using Web Services. There is the Microsoft Smart Client Factory which is most likely the closest thing I have worked with.
I mentioned the above 2 options since they already have libraries in .Net that work with them directly, either as a referenced Web Service, or for the more adventurious, myself included, using the WebClient library or alternatively the new HTTPClient library in the WCF REST Starter kit.
I have used both, in Windows, Web, Silverlight and WCF. The latter being the easiest since they are focussed at REST.
We are currently investigating Prism which strongly leans to using this method when using WCF for front-end development.
Assumption
With regards to this question, you are making a generic assumption that wrapping ADO Entity Framework with a WCF service it will be generic. ADO.Net Data Services is the closest you will get, however the structure of the database will fundamently change the way you interact with it. Going a level higher in a "generic" way would be dangerous, as these 2 technologies, individually or together, are already as generic as possible.
In addition to Data Services (+1), consider RIA Services. It's like a domain-specific version of data services for Silverlight or WPF clients. Less flexible, but easier, than Data Services.