Good morning,
I am taking over from someone who has been using the Entity Framework to communicate with a database. How this has appears to have been done is that there is a WSDL that describes all of the objects that we use created in Enterprise Architect. This is then imported as a Service Reference in Visual Studio.
I am a bit confused by this so was wondering if it is a sensible approach. The WSDL has a sample port, binding and service that appears to be not used at all in the code. Do these exist in order that the WSDL gets imported properly?
I looked on Google and couldn't see any examples of people creating from WSDLs in this way so wasn't sure it was a common approach.
So when this is done you have the representations of the data as classes. Then it seems you add them to a class inheriting from a DbContext which creates the tables in the database. Is this correct?
If you are using WSDL just to get data from EA to VS it is of course completely wrong. WSDL describes web service - port and binding are mandatory for service description.
EA Professional edition and above has direct support for code generation from the model. You just have to set which language you want to use (in Project browser select folder containing your classes and interfaces and set language in properties) and then you can use Tools > Source Code Engineering > Generate Package Source Code.
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 for an easy-to-implement solution for form-based ontology editing and I wonder if there are any active projects and which of them is the right path to follow.
I need to create instances of an ontology (lets call it ontology A) using forms (either web or desktop) and store them in a triple store (e.g. Virtuoso). I would like to hide as much details as possible regarding the ontological relationships between the entities defined in ontology A and provide a plain simple user interface for CRUD (Create-Retrieve-Update-Delete) operations based on the entity schema defined in ontology A.
For example, I have found two possible solutions in the protege ecosystem:
PropertyFormPortlet It is not a live feature in the current webprotege version.
facsimile project
As described in the respective paper this is a solution that has been implemented for a specific context. Therefore, adapting it to another domain would not be as straightforward as I would like.
I wonder, is there another solution (even out of the protege ecosystem) that could facilitate such a form-based ontology editing. Could somebody provide some guidance?
Just in case someone lands in this question, I write down my conclusions. Practically, none of which I tried worked, but still I found out some interesting things.
OpenLink Structured Data Editor:
OSDE is a browser plugin which aims at populating RDF graphs in the form of files, based on Linked Vocabularies. In my case it didn't work as my locally hosted ontology cannot play the role of a "Linked Vocabulary". However, OpenLink team said they will work on it.
OData2SPARQL:
In our test, the WebIDE did not manage to create the forms out of the box as suggested by the respective video tutorial. However, we managed to use OpenUI library as a client of the OData services automatically created by OData2SPARQL, providing a web service interface for our ontology.
Ontowiki:
In our test environment, OntoWiki partially worked. We could save data but there were some bugs when trying to add properties etc. OntoWiki developers said that they plan to refactor in order to actively support it in newer hosting settings, but this is not the case right now.
I share a Data Transfer Object between an C# Azure Mobile Services server and client. I use the same class in both applications.
The TableController class used by Azure mobile services requires the DTO to inherit from 'EntityData', which in turn implements interface 'ITableData'.
ITable Data lives is part of reference:
Microsoft.WindowsAzure.Mobile.Service.Tables
I have not figured out how to include that reference without installing the entire server-side mobile services package in nuget:
WindowsAzureMobileServices.Backend
That includes OWIN, and many other references the client does not need. This is what I am doing currently. This works for a desktop application I am currently working on, but I think it will not work for universal apps and windows phone apps.
I also looked at microsoft's samples for mobile services, and there they use separate classes as DTOS for server and client.
Is it really the case that we have to write the same code twice?
No, but you could better make use of Shared Projects, and partial classes.
Your Shared Project will have common properties for the entities.
Other projects will reference this Shared one, and can add some other properties to shared entities, still using partial classes.
I have precise experience with AMS, so I know what you are meaning.
In my experience, is anyway not realistic to think to have exactly the same entity classes for client and server.
For instance, in so called Portable Class Libraries you can have a very small subset of framework, and references available.
Other than properties, you normally put attributes on POCO class files. On the client you may have some attributes that aren't available/meaningful for the server (e.g. SQLite attributes), or viceversa. You may can get stuck in this situation also with the shared projects approach I suggest, but it could be managed there with what so called preprocessor directives.
I have a couple of web services running on JBoss 5.1.0 GA with JBossWs native stack (shipped with JBoss 5.1.0 GA binary)
These web services are simple POJO services. Many of the WebMethods exposed by the services are of Complex Object type (I call these Complex types as DTO's) and a lot of custom defined exceptions. These DTO's are also bundled in a jar file, so that they can be used at the Client end as well.
I started creating a client using Eclipse (which I understand is using wsconsume to generate the client stub) and I saw that the utility would generate the DTO's from the WSDL and I could not find any way of enforcing the utility to use the DTO & exception classes provided in the jar file.
I had earlier asked a question on this on SO and could not find any answers.
From reading of various resources on wsconsume and generating client stub using eclipse (which would use JBossWS) i have now started to believe that what I am trying to achieve might not actually be possible using wsconsume.
My question is:
Is there a better way to create a client stub which would use the DTO classes from the jar files. I am open on changing the Client generation mechanism and move to axis or any other library for Client generation if that is possible. It would also be ideal if an ant task can be created for Client stub generation.
PS: My knowledge on web services is very limited and if I am being stupid with my question here, please pardon me for that.
Why do you want to use Data Transfer Objects in Your Web Service ? Is that necessary? Because If you use such objects, those web services can be use only in Java I think. That is a interoperability issue. So If you can avoid those kind of objects that will be a good practice.
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