We are creating an integration application which will sync data between Dynamics CRM and Xero. We are now at the stage where we need to decide which type of application we should use to connect to Xero and perform operations.
The application will be used by multiple Xero Customers. So our application should serve multiple Xero users.
We will have web api which will call on Dynamics CRM events(Create, Update Contact etc.) and will update the data in Xero.
So our web api should connect to Xero and perform operations in Xero. We tried using Public application but it generates the token that is valid for 30 minutes. The web api should communicate to Xero without any time limitation.
Please suggest how we can achieve this.
You should begin developing your integration using a public application, and get in touch with Xero to register for becoming a partner application (which will give you the ability to request long-term tokens). The process is documented here: https://developer.xero.com/documentation/auth-and-limits/partner-applications
Related
I'm designing an architecture where the web interface is a client (developed using a front-end js framework) and all requests are routed to several webservices.
All communication will happen using standard HTTP responses and JSON entities.
Now I'm facing the authentication mechanism.
My service will, of course, have several users, and I need to restrict access to users' resources.
Users will 1) signin to the web client (/admin) and then 2) the client-side js will perform several AJAX requests on webservices on user behalf.
Should I create a persistent session between the client/server and then pass some reference alongside each request or authenticate each single request using a stateless approach? How could I authenticate the web-client requests for the current user without adding too much overhead or complexity to my system?
I'm looking at passport-local and passport-localapikey but it's not very clear to me if I should authorize my client or the user itself (meaning should I have only one pair of credentials for all users when performing web-service request or one pair per user?)
A simple example (explained I don't need to copy-paste code) would be very appreciated. At this stage I'd prefer the solution introducing less complexity but granting a good security in order to be able to set it up very quickly.
PS. I could also take into account creating a distinct service handling authentication in order to create a common API to be shared between client and server, but that seems a bit over-engineering to me.
Thanks,
If you're already using Express as a framework for Node.js, you can use it's built in session handling. It is capable of using any sort of session store including memory, redis, mongo, etc.
There's a good example here: http://blog.modulus.io/nodejs-and-express-sessions
I am working on a WP 8 app which I would like to connect to an on-premise(local) web service. I have managed to do so using simple BasicHttpBinding without secuirty and Azure Service Bus Relay, but i cant manage to make a secure connection. WP 8 only support BasicHttpBinding, and thats my biggest problem so far.
I understand that Azure mobile service is an efficent and easy way to securly connect your WP 8 app to the cloud. Is it possible to access an on-premise web service through Azure mobile service? And if possible, could it be done without exposing all the content of the local service publically via Azure Service bus relay?
You should be able to do this securely from WP8 -- I'm not quite sure why it's not working -- but even if you had to roll something yourself, it should be possible (example, check out this post from Michael Collier on doing something similar: http://michaelcollier.wordpress.com/2011/08/19/azure-sb-and-wp7/)
To the question, though, WAMS (Windows Azure Mobile Services) is definitely easy to use, but it wouldn't be feasible to do what you want -- that is, to be a public endpoint in this fashion. In short, WAMS gives you an easy to use CRUD interface to data that happens to also expose features for authentication and notifications, and at the same time gives you some server-side javascript to do custom work -- such as calling out to other services, sending emails or notifications, etc.
But, each request into WAMS is essentially mapped to a CRUD operation on a database table. While you could likely 'inject' a simple call, this isn't what you want. It sounds like using the service bus is the right way to do this and should be possible...
Lets have an example scenario:
Client opens a web site and finds the sum of two numbers which he enters from the textboxes.Then clicks on the ADD button.Two parameters are HTTP GET'ed to server where PHP code is written to add the numbers and result is echo'ed.
Based on this scenario could anybody explain the difference between Web services and application?
In your case if you have User Interface for providing two numbers and then getting the result, it should be called a web application. But if you have an API exposed to receive two numbers and return result over http , then it should be called a web service.
At low level, both Web application and web service are kind of same thing. But the main point is that web services are for machine/program to machine/program communication whereas Web application is for Users.
I'd say that web applications are intended for users and web services are intended for other applications. That's the most important difference. Web applications usually present data in HTML which looks nice to the user and web services usually present data in XML which easy to parse by other applications.
A person drives a car. That car could be powered by an internal combustion engine, electric motor, or nuclear reactor. The power source doesn't matter to the driver though, as all they need to see are the controls and the road ahead.
The application is the car. Web services are the nuclear reactor.
To add 2 no.s we write a web service, to subtract we write a diffrent web service, however calculator is an web application that uses add,subtract and many other webservices in combine.
Lets take an example of Google search.
We can use Google search in two ways. First, we can visit http://www.google.com and put out query for search. Google the returns the result. Second, we can integrate Google Search in our websites with custom search API.
In first case Google Search is acting as web application while in second example it is acting as web service.
Here we can point out few differences,
User interacts with web application while machine interacts with web service.
To access web application, one must visit application. While web service can be access from anywhere (from any application which integrated it). We don't need to visit the service explicitly.
A webservice is equivalent to a method in java that has a web wrapper around it. It lives on the server and it can be sent data / queried etc. and may or may not return a result. It does not have any front end it can only be accessed via http get, put, delete etc.
A web Application is a fully functional piece of software that lives on a sever that is designed to help people achieve a task. This would have a front end that would allow users to interact with it / enter data etc.
A web application could use multiple webservices to achieve its goal / end result
There is little difference between web application and web services.
Web Application: In web application when user request any data then the server embeds the response into some HTML and forward it to the user and on browser the HTML is rendered.
While in web services it's done differently that when some user requests for some data then the server returns it a json or XML array of objects and the data can be displayed by anyway the web designers wants.
Thanks Hope it resolves the matter.
Web service is for application consumption , invoked through web application
To communicate with webservice data should be sent as SOAP message or as REST i.e XML over HTTP
Most of the times web service is not part of application because to facilitate the use by other web applications and it is not for direct consumption to end users
Web application is for human consumption invoked directly by GUI which may or may not use web service for giving response
This is really a stupid question.. I really can't figure this out so need help
Basically, our web application will exchange data with another software company web application. That company has already exposed their webservice, and we can perform crud operation via their rest api. If we can full fill our requirement via their rest api, do my software company need to build our own webservice server? In which case do company build their own webservice server?
You should only need to create a webservice on your side if the other application needs to request and consume data from your application. If you're merely passing data to their API and consuming the response, there should be no need for you to create an API.
The Window desktop application provides C++ API that gives an array of customer information such as name and address. I want to expose this as SOAP Web Service with Security so that authorized clients (from remote servers Linux/Java based through ESB) of this web service can get this information at any time they want in SOA implementation (Java based).
The desktop application does not have a standard database. It stores its data internally. Its basically old custom built CRM application that is installed on each agent's PC box. Each agent has its own list of customers.
What are the steps to achieve this task?
Do I need to run this as Windows service?
The short answer is, yes, you can expose data from a desktop application through a SOAP web service. It is easier to do with C# and .NET, but not impossible to do from C++. What steps you need to take will depend on which platform you are developing for.
Roughly -
Implement an endpoint that supports SSL where clients can connect to your desktop application (using sockets in C++ or HTTPListener using .NET).
Write code that can receive and dispatch SOAP requests.
Handle SOAP requests and return properly formatted SOAP responses.
Handle WSDL requests.
Implement a security mechanism (cookie based or otherwise).
Using .NET, most of this is in the platform code already, you just have to put the pieces together. With C++, you may find some third party libraries but essentially you'll be writing your own.
You only need to implement a windows service if you want the data to be available while a desktop user is not logged in and running your desktop application. The challenge here is that you'll have to make sure the windows service can access the same data the desktop application is using.
Another strategy would be to access the data from your desktop application using the C++ API and Interop and implement the web service as a standard out of the box asmx hosted on IIS.