WSO2 community.
Exists some predefined API (as WEB-SERVICES ?) or Java API (carbon maybe) to integrate this. (Need some basic facilities as create/delete user/tenant/database, get existent databases etc.) or should I start to develop this web-services in SS?
TY!
You can use these soap services.
RSSAdmin - to provision databases
RemoteUserStoreManagerService - for user management
TenantManagementService - for tenant management
Related
What exactly is their relationship?
When installing API-M, are both of them installed at the same time?
The functions supported by both are different, but when they work, do they work together?
If not, should the user choose to install one of them?
Please explain in detail about the relationship between API Gateway and Choreo Connect.
Choreo Connect is the new name for one of our existing products - Micro-gateway. The Standard Gateway and Choreo Connect/ Micro-gateway are designed for different use cases. Standard Gateway is more suitable for VM-friendly, old-fashioned application whereas Choreo Connect designed keeping Cloud-native development in mind.
Choreo Connect is container friendly and does not require lot of processing power and memory and with its faster startup, it's the ideal solution for cloud-native applications.
Both are two different downloadable products.
The features they offer more or less similar as well.
When deciding which distribution to use, ask yourself what type of application architecture you are planning to use. If it's old-fashioned monolith type of application, Standard Gateway is more suited. If it's Microservices/ Cloud-native, then Choreo Connect is more suited.
More info on Choreo Connect - https://wso2.com/choreo/choreo-connect/
API Gateway is a synapse based gateway that comes by default with API Manager. Choreo Connect is a lightweight micro-gateway which is compatible with APIM 4.0.0 and newer versions.
You can find a detailed comparison in [1].
[1] - https://apim.docs.wso2.com/en/latest/deploy-and-publish/deploy-on-gateway/deploying-apis-in-api-gateway-vs-choreo-connect/#deploying-apis-in-api-gateway-vs-choreo-connect
In WSO2 APIM synapse gateway is used (it's the in built API gateway in WSO2 API manager). How ever you can use Choreo Connect as the Gateway with WSO2 API manager as well (as a replacement to the synapse gateway). (If you are familiar with the WSO2 Ballerina API Gateway, Choreo Connect is the new version of it.)
When it comes to the comparison of above two gateways, Choreo Connect mainly aims Cloud Native Environments. You can use Choreo Connect with or without WSO2 API manager.
Additionally Choreo Connect supports Kubernetes based and Docker-Compose based deployments.
You can use below links if you want to get more idea about Choreo Connect
Comparison between Synapse (Gateway used in the WSO2 API ) and Choreo Connect
Choreo Connect supported features
Choreo Connect Quick Start Guide
Choreo Connect with WSO2 API Manager
Choreo Connect in stand-alone mode
I´m interested in using the store and the developer portal. In some cases I want to integrate third-party gateway like kong.
The documentation from WSO2 API Manager 2.x says:
- Components usable separately: developer portal can be used to catalog
APIs deployed in third-party gateways
(https://wso2.com/api-management/features/)
Do you have more information about that feature and how to configure it?
Technical this is feasible but requires some work. I've found that someone did it with Intel Expressway Service Gateway.
You would need to implement a custom handler in WSO2 and connect it with Kong. But as the features might differ, the UI may not perfectly fit.
Besides than offering extension points, WSO2 has no real interest in supporting this as the API Gateway is the core component and all of their business models are based on it.
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).
My question is really about the difference between API Management in Bluemix and API Management on Cloud?
In the docs on Bluemix I can see
"This service includes API versioning, lifecycle management, and API usage analytics."
In the knowledge center about the Cloud version is says
"The API Management environment provides the following functions:
Manages the operations of the various servers in the API Management environment.
Provides the tools to interface with the various servers.
Provides analytic functions that collect and store information about APIs and API users.
Processes and manages security protocols and stores relevant user and appliance authentication data.
Provides assembly functions that enable APIs to integrate with various endpoints, such as databases or HTTP-based endpoints.".
So, is this the same?
according to the documentation it is the same service. The differences should be related to available pricing plans, on Bluemix there is just one pricing plan.
I am trying to port my Android application into a Cloud based one. Where I wanted the data stored in cloud. I am a .NET guy so looking into Azure. I see Azure Mobile services which allows me to create tables and ability to authenticate. I also Looked into Azure SQL database.
I would like to know what is the difference between these two services and what are the scenarios using mobile services gives values than using Azure SQL database
Actually, the tables you see listed in Azure Mobile Services are actually tables that are in an Azure SQL Database instance. The Mobile Services provides an abstraction layer on top of the tables in SQL Server. If you use the current JavaScript back-ended mobile services you'll see the table in the management portal and it uses the dynamic nature of JavaScript to provide what appears to be a NoSQL like experience with Azure SQL DB in that you can send in an object and properties it doesn't recognize will be added to the table schema (you turn this off when you ship to production :) ). The big thing to remember is that under the hood the database is an Azure SQL DB, so you should have access and do anything via the one created by Azure Mobile Services as you can with the raw Azure SQL DB.
By using Azure Mobile Services you get an API hosting layer that you can use to do direct access to the tables (based on the permissions you hinted at) but also to just about anything utilizing the custom API feature.
If you chose to bypass the Azure Mobile Services you'd likely want to have some API layer between your Android app and the data for a variety of reasons (security, abstraction of data location, etc.). In which case you'd have to write and host that API layer somewhere. Other options within Azure would be a Web API site in Azure Web Sites, an API hosted in an Azure Cloud Service or all the way up to an Azure VM; however, as you slide up that scale you're taking on more and more responsibility and work.
The scenario that is useful to use Azure Mobile Services over the Azure SQL DB is pretty much the scenario you have. You don't have to maintain your own hosting API layer, just the code the API layer executes. You can scale an necessary (to a very large scale indeed) and also get features like the push notifications and web jobs (though those are also things you can do via other services in Azure if you'd like). Thinks of Azure Mobile Services as a higher level grouping of Azure services that are helpful to mobile developers.
Mobile services provide you with built-in push notification features and other such mobile friendly features too. They are more mobile oriented in a way.