Scenario: After creating and adding an API in API exchange, we can add a policy like a rate limiting to it. After the policy is created we have the API fragment that we copy and paste in our RAML API specification.
My question is can we define the policy in RAML and implement the policy logic directly in the Mule app and remove the API Proxy in between.
If yes, can someone also please share the link to examples if there are any?
Add an autodiscovery element to your application. This is the Basic Endpoint use case described at https://docs.mulesoft.com/api-manager/2.x/api-auto-discovery-new-concept#proxy-endpoint-vs-basic-endpoint and https://docs.mulesoft.com/api-manager/2.x/configure-autodiscovery-4-task (assuming you are using Mule 4).
You need to configure everything manually, instead of the proxy which is autogenerated.
You can't do this in RAML as you described in your question.
but to add any policy logic other than the policies that are available in your API Manager, you can create your own custom policy and after creating upload that in your API manager and apply them.
Thanks
Related
I have a question regarding Autodiscovery, and adding code fragments of policies to an API specification.
Using Autodiscovery, we can apply policies and it will be applicable to the deployed application. For example Rate limiting policy applied through Autodiscovery will work fine to manage the access of our API.
Then what is the purpose of adding Client id enforcement or adding the code snippet of this policy to the API RAML? Does this mean that once the RAML changes are done, we again need to update out code to include this new RAMl from exchange and redeploy our application?
The purpose of the snippet is to document that client_id and client_secret have to be send as part of the HTTP request to the REST API. It will also make APIKit validate that it is receiving the expected information for the policy to work.
How to add Azure custom Policy for Azure Data Factory to only use Azure Key Vault during the Linked Service Creation for fetching the Data Store Credentials instead of credentials being put up directly in ADF Linked Service. Please suggest ARM or PowerShell methods for the policy implementation.
As of yesterday, the Data Factory Azure Policy integration is available which means you can now find some built-in policies that can be assigned to ADF.
One of those is exactly what you're asking for as you can see in the image below. You can find more information here
Edit: Based on your comment, I'm editing this answer with the info you want. When it comes to custom policies, it's pretty much up to you to come up with them and create what fits your needs. In your particular case, I've created one policy that does what you want, please see here.
This policy will audit your data factory linked services and check if they're using a self-hosted integration runtime. Currently, that check is only done for a few types of integration runtimes (if you look at the policy, you can see 5 of them) which means that if you want to check more types of linked services, you'll need to add them to the list of allowed values and select them when assigning the policy definition.
Bear in mind that for some linked services types, such as Key Vault, that check won't make sense since that service can't use a self-hosted IR
We are planning to create a custom webservice solution on APIGEE.
Our requirement is create a single API PROXY which should be serve for more than 2 WSDL.
All WSDL contains different Operation and Binding.
Also data type defined in schema also entirely different.
Our main objective is no need to modify the API PROXY for any customer in the future.
Also want to utilize the OAUTH service provided by APIGEE for authetication.
Can you please tell how feasible in APIGEE?
I'm exploring WSO2 API Manager platform to use in Open API project. The idea is that we forbid registration in Store and creating users by ourselves. But we also want to give them only Sandbox API as a starting point and then, explicitly allow particular users to consume Production API. Haven't find any information. Is it possible? If yes - where to look?
You can restrict the token generation for the Production endpoints by using Workflows. Follow the documentation[1].
You could configure ProductionApplicationGeneration to use ApplicationRegistrationWSWorkflowExecutor and SandbobApplicationGeneration to use ApplicationRegistrationSimpleWorkflowExecutor.
With this approach if the subscriber tried to generate a token for production endpoints, it will trigger a human task, which needs to be approved from the Admin Portal.
For your requirement, you could write a custom workflow extension which allows restriction by role or user name. For more information on Writing custom workglow extension please follow [2]
[1] https://docs.wso2.com/display/AM210/Adding+an+Application+Registration+Workflow
[2] https://docs.wso2.com/display/AM210/Customizing+a+Workflow+Extension
Thanks and Regards
I can see that you have some expertise with REST API's and PEGA. I would like to know if we expose web call using REST API's to PEGA, will we get all custom rules and all or we need to replicate the rules?
Regards,
Sudhanshu
If you are consuming the REST API and will be using Pega as the REST client, you do not have to create the rules manually. There is an accelerator ("wizard") that will create the rules for you, based on an example request/response for the REST API.
REST mean "Representational state transfer" in pega to create the REST , it provides widget by using widget we can create it. Please visit the link for more updates:
https://myknowpega.blogspot.com/2019/04/pega-81-application-development.html
Since your question is not entirely clear, let me specify for both options (i.e., connector and service). Besides, I am assuming you are using the latest version of PEGA
Integrating Pega with an external service (via Connect-REST)
This can be achieved using the integration wizard by navigating as specified below Configure -> Integration -> Connectors -> Create REST Integration
Documentation to achieve it step by step is listed here
https://docs.pega.com/data-management-and-integration/84/creating-rest-integration
Pega Exposed as a service to external systems via Service-REST
It is bit of a manual process involving creation of service packages, service-REST rules and the configuring the methods GET/POST/PUT/PATCH/DELETE and its corresponding responses.
Documentation on the same is available here as indicated below.
https://docs.pega.com/data-management-and-integration/84/service-rest-rules