In our project, we need to work on multiple services. so started implementing Spring cloud contract testing between two services. (internal services ex: BookService, Employee Service)
Our Requriment:
How Can I implement Spring cloud contact for Third-party service( ex: AccessService) where we can access only API's but no control on Dev Code Base.
The base idea of contracts is that you can ensure that the producer API matches the requirements codified in the contract files. If that is not possible (you don't own the producer code base and you cannot do contract PRs to producer codebase), this approach will not be helpful for you. So you can use contracts for the services in which you can verify producer code against them and use a different approach for external services.
Related
We have Scheduler Jobs transfer data from Source to Destination (Employee Data to Systems or Filemovers (Configures in property files))
We have Rest API exposes data related to entity (For example Employee or Organisation)
We have Wildfly on Linux (cluser), Oracle and Java Integrations deployed.
Manager ask to provide IAAS i.e Integration as a Service. As we are already exposing Rest API; what more comprises IAAS?
I want to config Keycloak to work across multi-tenancy / realms, so how to config client to work across multi-realms?
If you have a client application that is multi-tenant aware and every tenant is mapped to a different realm, different clients within a single realm, or a combination of both, you may want to implement a KeycloakConfigResolver in your client application and keep sepearate configs per client.
Assuming you are using Java and OIDC, check out the adpater documentation for multi-tenent support.
I am using a Logic App for which I need to create a custom connector. This connector depends on a web service, for which I am trying to add using wsdl definition.
Now If I provide the url, it needs authentication, which I am not able to provide via this UI. I can see the parameters can be provided while using it in the logic app. However it fails to pull the services and hence not creating the definition for the connector
I tried downloading the wsdl and adding here as a file, but the schema have xs import tags, because of which its failing again. And as per this answer, I can not replace it with actual schema.
<xs:import namespace="http://some.name/" schemaLocation="./path/to/it.xsd"/>
Is there a way that I do not need to provide the custom connector definition manually and make it work using wsdl, as it contains a lot of endpoints and it would be too much to add all actions and triggers manually. Plus it would be also reference for me if needed in future for such scenario
You may try this if the services are accessible over the internet, then you call service endpoint over HTTP or HTTPS from azure logic apps. This article will help you with details steps to be followed: https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http
If it is not accessible over the internet then this article will help with step by step process: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
Before you can access data sources on premises from your logic apps, you need to create an Azure resource after you install the on-premises data gateway on a local computer. Your logic apps then use this Azure gateway resource in the triggers and actions provided by the on-premises connectors that are available for Azure Logic Apps.
Also check this
I am building REST APIs with MicroServices, which means I have different services for providing different resources. Suppose I have below services:
ServiceA is providing resources resourcesA and resourcesA1 with below URLs
https://my-internal-endpoint-for-serviceA/resourcesA
https://my-internal-endpoint-for-serviceA/resourcesA1
ServiceB is providing resources resourcesB and resourcesB1 with below URLs
https://my-internal-endpoint-for-serviceB/resourcesB
https://my-internal-endpoint-for-serviceB/resourcesB1
Now, I want to manage them in Azure API Management. To publish them (by importing the Swagger document from services), API Management portal need an API path for publishing. So, serviceA and serviceB can be published as below:
https://my-api-azure-api.net/serviceA/resourcesA
https://my-api-azure-api.net/serviceA/resourcesA1
https://my-api-azure-api.net/serviceB/resourcesB
https://my-api-azure-api.net/serviceB/resourcesB1
But to be more resources based API management, I am expecting the published APIs to be more like below:
https://my-api-azure-api.net/resourcesA
https://my-api-azure-api.net/resourcesA1
https://my-api-azure-api.net/resourcesB
https://my-api-azure-api.net/resourcesB1
Unfortunately, API management does not allow me for pubshing 2 APIs (serviceA and serviceB) to same path (root path in this case). I don't want to put the service name (or something equivalent) in the URL path as the service name is something duplication of the resource name provided by it. How do I workaround this?
The Azure API Management Policies can help you here, in particular the control flow with the ability to forward requests. The documentation is here: https://learn.microsoft.com/en-us/azure/api-management/api-management-policy-reference
I would approach this by setting up the resources as a single API, by adding one via swagger and then adding in the other services to this one to make it complete (as you want it to appear as a single complete service). Once this is in place you are then free to apply the policies.
Note: you may have to expand the resource path in the following way
https://my-api-azure-api.net/mynewservice/resourcesA
https://my-api-azure-api.net/mynewservice/resourcesA1
https://my-api-azure-api.net/mynewservice/resourcesB
https://my-api-azure-api.net/mynewservice/resourcesB1
Maybe the answer to this question can help:
How to chain APIs using Azure API management
You can use the same policy to map several operations of the same API in API Management to different backend APIs.
But in general all APIs are exposed as <myGateway>.azure-api.net/<myApi>/<myOperation>.
How can I create multiple instances of a bundle that consumes an external webservice?
An external webservice requires clients to logon before using the services. I have multiple accounts. The problem is I want to be able to add multiple instances; one for each account. Each instance is an osgi declarative service that consumes the external service.
Do I have to deploy a new bundle for each account? This does not feel like the right way to solve this.
What you need is multiple instances of an OSGi component or service, not multiple instances of a bundle.
I'd recommend a service factory, where each OSGi config that you create (account parameters in your case) for your service causes a new instance of a service to be created.
Neil Bartlett's tutorial at http://njbartlett.name/2010/07/19/factory-components-in-ds.html looks like a good starting point for that.
Is that bundle under your control - can you refactor it ?
If yes, it might be useful to expose a client factory service, rather than client service itself.
Then each instance can log into a different account.