We are starting to implement workday and had a question regarding whether workday can call an external webservice.
Workday definitely can call external web services. Workday offers an integration platform with an Eclipse based IDE. It is a full ESB platform that can call http(s) SOAP and REST services. There are complex orchestrations with flow control and transformations. It is an extremely powerful integration platform that some of the world's largest firms use to integrate with third party systems.
The api's described previously are for inbound data flows from external systems.
Workday allows outbound calls using their "outbound subscription" service.
This integration pattern is described here:
https://community.boomi.com/docs/DOC-2614#jive_content_id_Outbound_Subscriptions
A more reliable integration pattern is to use message queuing:
https://community.boomi.com/docs/DOC-2614#jive_content_id_Message_Queuing
How should the external web device call be triggered?
I believe doing a soap or restful web service call from a Studio solution would be relatively simple .... As long as workday does not limit outgoing connections from a studio integration.
There are some security limits on what what an integration can do - such as they are not allowed to read local files (on the workday host) using Java IO routines , etc
It appears there is an API. https://community.workday.com/api
Hereis the web services documentation.
https://community.workday.com/custom/developer/API/index.html
Workday offers an open, standards-based SOAP API for programmatic access to our On-Demand Business Management Services. The following directory provide the API Documentation for our multi-tenant SOAP-based web services with corresponding WSDL and XML Schemas (XSD's).
Related
I have a query on a design hope you guys can clarify my doubt.
I have a specific requirement in which Mule is used just to expose the back end services in API gateway, backend services are written in Spring boot and other technology, all these services needs to be exposed in API gateway.
Is this a good practice to do that and if yes how can we do that?
I saw that in API manager we can create proxy layer on top of the services developed in Mule but is it possible to create proxies for the services developed in different technologies?
Absolutely ... For creating proxy service, it doesn't matter what type of technology does the backend service have.
It can create a proxy layer for any kind of backend service available either locally, in cloud or other remote location till the service url is accessible.
This proxy will create an additional layer hiding the actual url to the external world.
it doesn't matter what technology you are using for development as long as those are REST services and accessible to the cloudhub application. You can deploy those on-premise and can integrate your local runtime with cloudhub. Also, mule supports spring projects and you can directly configure your spring project/details inside mule.
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I want to build a new mobile app backend. This backend might eventually support other types of clients such as desktop or traditional web application.
In the past for multi client applications I would use this stack of technologies. SQL Server -> Entity Framework -> TCP WCF Service Endpoint -> MVC Web Application or WPF Windows Application
I know I want my mobile client to be consuming a Restful Http Web API like the types you would host in the new Azure API product. But I'm not sure if I should still do the WCF layer or not.
Couldn't all my clients consume just the Web API now? Or would it still be wise to develop the WCF service and the layer Web API on top of that?
It just doesn't seem right to be using 2 different serialization technologies at the same time.
Yes, you could replace that with Web API and create a REST API but as Tim already mentioned on his comment, that is obviously just HTTP and not all the protocols WCF supports.
Having said that, API Apps have Swagger metadata to describe what the REST URIs (endpoints) can do (e.g. methods, content types, descriptions etc.). There are a lot of Swagger SDK generators which can read the Swagger metadata and generate the code you need to consume the REST API in your application for pretty much any language out there. For Visual Studio 2013 with the latest Azure SDK, you have this capability built in as well. This is pure code generation, no tight coupling or anything, we just generate the code you were supposed to write to consume the API.
I'm planning to develop a pos application for restaurant. Client will be using pc and mobile. Application will be used in local area connection. I'm still considering whether to go with wcf or web api. What are the advantages of using wcf/web api for the type of application i'm building?
Use WCF to create reliable, secure web services that accessible over a variety of transports.
Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients.
Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API.
If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.
from the official Microsoft Documentation.
Essentially, my take on this is that WCF is much more difficult to work with, and not completely compatible out of the box with many mobile clients, so only use it if you know that it's something you need.
Is there any third party tools available to Monitoring WCF Service?
I have created WCF Service with 5 Methods (OperationContracts) and Hosted in IIS.
Does there any tool available to specify how many times each method was called and what is Request and Response of the each call ? (Similar to SQL server profiler).
Use standart tracing and diagnostic tool for WCF, and work with .svclogs using SvcTraceViewer.exe application.
If you host under IIS, use AppFabric. It a great tool, when you can easily manage the settings of your services, including tracing and diagnostic. There is a nice article about using it http://www.dotnetcurry.com/ShowArticle.aspx?ID=771
The AppFabric Dashboard provides a centralized gateway to view and manage the health of WF and WCF services deployed locally or to a server farm. It exposes real-time data from the Persistence database and historic data from the Monitoring database, and it allows you to “drill down” to examine instance and WCF Call metrics in greater detail.
http://msdn.microsoft.com/en-us/library/ee677236(v=azure.10).aspx
AppFabric helps to monitor WCF service like How many time the operation is invoked, Errors/ Faults and also supports historical data.