I have a pipeline I need to cancel if it runs for too long. It could look something like this:
So in case the work takes longer than 10000 seconds, the pipeline will fail and cancel itself. The thing is, I can't get the web activity to work. I've tried something like this:
https://learn.microsoft.com/es-es/rest/api/synapse/data-plane/pipeline-run/cancel-pipeline-run
But it doesn't even work using the 'Try it' thing. I get this error:
{"code": "InvalidTokenAuthenticationAudience", "message": "Token Authentication failed with SecurityTokenInvalidAudienceException - IDX10214: Audience validation failed. Audiences: '[PII is hidden]'. Did not match: validationParameters.ValidAudience: '[PII is hidden]' or validationParameters.ValidAudiences: '[PII is hidden]'."}
Using this URL:
POST
https://{workspacename}.dev.azuresynapse.net/pipelineruns/729345a-fh67-2344-908b-345dkd725668d/cancel?api-version=2020-12-01
Also, using ADF it seemed quite easy to do this:
https://cloudsafari.ca/2020/09/data-engineering/Azure-DataFactory-Cancel-Pipeline-Run
Including authentication using a Managed Identity, which in the case of Synapse I'm not too sure would resource should I use. Any idea on how to achieve what I want or if I'm doing something wrong?
Your URL is correct. Just check the following and then it should work:
Add the MSI of the workspace to the workspace resource itself with Role = Contributor
In the web activity, set the Resource to "https://dev.azuresynapse.net/" (without the quotes, obviously)
This was a bit buried in the docs, see last bullet of this section here: https://learn.microsoft.com/en-us/rest/api/synapse/#common-parameters-and-headers
NOTE: the REST API is unable to cancel pipelines run in DEBUG in Synapse (you'll get an error response saying pipeline with that ID is not found). This means for it to work, you have to first publish the pipelines and then trigger them.
Related
On Pulumi, I have started working with the Auth0 provider (https://www.pulumi.com/registry/packages/auth0/) and I ran into a problem. I'm trying to configure custom database connection with Auth0. I'm using auth0.Connection. When I run pulumi up it says my connection resource was created but I see no update on the Auth0 web ui (what is on web ui is not what I have sent with pulumi). When I run pulumi up (multiple times) it always says the plan is to create the "options" on my connection again. Even though nothing has changed since the last pulumi up. I'm provisioning Connection like this:
auth0.Connection(
f"{name}-connection",
options=auth0.ConnectionOptionsArgs(
brute_force_protection=True,
custom_scripts={"login": login_script},
debug=True,
disable_cache=True,
disable_signup=True,
import_mode=False,
name="Database Connection Opts",
tenant_domain=auth0.get_tenant().domain,
),
strategy="custom",
enabled_clients=client_ids,
display_name="Database Connection",
opts=opts,
)
When pulumi up shows the plan it says: auth0:index:Connection auth0-connection update [diff: +options] . So I understand it plans to include the options. After executing the plan it says
Resources:
~ 1 updated
...
When I go on and run pulumi up again, it does exactly the same: try and update Connection by adding the options. The impression is that Pulumi/Auth0 declared it had added the options but in reality, it didn't.
Does anyone have any clue what I might be doing wrong? Or is this a Pulumi/Auth0 bug?
We're calling a REST-API technical profile in the OrchestrationStep. In the event where the REST-API returns an error, it redirects back to the application and displays the error as a query string.
(e.g.#error=server_error&error_description=AADB2C%3a+No+code+provided%3a+Conflict+error%3b+RequestId%3a+No+request+id+provided.%3b+Additional+Info%3a+No+additional+info+provided.%...)
Is there a way that instead of displaying the error in the query string, it will display a custom error page?
Also why is api.error not displayed in this case?
Note: The REST-API is needed to be called in the OrchestrationStep rather than the ValidationTechnicalProfile
Assuming you are using Oauth/OpenId, the way B2C responds to the application is based on the response_mode query parameter that's passed to it when you call the policy. The response_mode can be query, form_post, or fragment.
Here's a link to the Microsoft's auth code flow docs that shows the response_mode query parameter in action along with it's available options: https://learn.microsoft.com/en-us/azure/active-directory-b2c/authorization-code-flow#1-get-an-authorization-code
api.error only displays for unhandled exceptions and doesn't cover every use case.
An answer to another post (Error handling in Azure B2C Custom Policy REST Call) from someone on the engineering team states that anything but a 200 from an API halts the journey execution and returns an error to the app immediately, so unless you put the rest call in a validation tech profile, this is the behavior you're going to get.
I'm trying to create a backend system with AWS API Gateway and Lambda.
In the past days I created a PUT method for a new API resource, with an API Key as a simple first security step. The PUT method invoke a Lambda function on AWS.
Then I deployed this API to a "prod" stage for some tests.
In the first days everything were working well as expected: I created a call to the API with postman and I received all the data I was expecting.
But a couple of days ago I started to receive always the 429 "Too many requests" response. I created also a new stage, but nothing changed: also the new stage, with the same version or with newer version, is getting always the same error.
The API is not reaching any limit, because they are called 4 or 5 times per day, not per second (checked on CloudWatch). There is no cycle, it is only a single invocation.
I suppose there is no error on the lambda side, because if I test the API in the AWS API Gateway console I get no error (and the lambda was working well in the past, no new changes from that version). The error only shows when I use an external client to test my api (in my case it is Postman).
Can anyone help to solve this problem?
UPDATE: I've just created a POST method on the same resource, with the same parameters and the same lambda. It is working. I wonder if the problem is related to the PUT methods in general or if within 2 days also my POST method will be affected by the same problem.
I had the same problem. I deleted and recreated the deployment. It did work in my case.
Here is a link to errors related to Amazon's API gateway. The last paragraph has additional information on the 429 error you discussed above.
I had the same issue. I created the case in AWS, and they suggested that I implement this dependsOn fix in the template file. Refer: Link
And it worked for me.
I am using SoapUI with Groovy script and running into an issue when calling multiple APIs. In the system I am testing one WSDL/API handles the account registration, and returns an authenticator. I then use that returned authenticator to call a different WSDL/API and verify some information. I am able to call each of these WSDLs/APIs separate but when I put them together in a Groovy Script it doesn't work.
testRunner.runTestStepByName("RegisterUser");
testRunner.runTestStepByName("Property Transfer");
if(props.getPropertyValue("userCreated") == "success"){
testRunner.runTestStepByName("AuthenticateStoreUser");
To explain the first line will run the TestStep "RegisterUser". I then do a "Property Transfer" step which takes a few response values from "RegisterUser" - the first is "Status" to see if it succeeded or failed, second is the "Authenticator". I then do an if statement to check if "RegisterUser" succeeded then attempt to call "AuthenticateStoreUser". At this point everything looks fine. Though when it calls "AuthenticateStoreUser" it shows the thinking bar then fails like a timeout, and if I check the "raw" tab for the request it says
<missing xml data>.
Note, that if I try the "AuthenticateStoreUser" by itself the call works fine. It is only after calling "RegisterUser" in the Groovy Script that it behaves strange. I have tried this with a few different calls and believe it is an issue calling two different APIs.
Has anyone dealt with this scenario, or can provide further direction to what may be happening?
(I would have preferred to simply comment on the question, but I don't have enough rep yet)
Have you checked the Error log tab at the bottom when this occurs? If so, what does it say and is there a stacktrace you could share?
Does anyone know the details about how to evaluate the XACML Policy? Actually, I've written one policy like the following, but when I tried to evaluate with Trylt tool, it always failed with the "Indeterminate". This is my first time to write an XACML policy, I am not sure what's wrong with it? Could you do me a favor. Thanks a lot!
And I used Trylt tool like the following to evaluate my policy like the following:
Subject ="admin"
It always failed like:(It happends as well when using the sample policy on IS)
The error msg is "Indeterminate"
My environment is:
The version of IS is 4.1.0
When you created your policy's you enabled?
That error happens regularly when the IS can not associate the criteria provided in the tool Tray It with existing policies in the IS
I recommend reading the following blog
http://pushpalankajaya.blogspot.mx/2013/06/try-out-xacml-policies-with-wso2.html
I guess, it can be due to this [1]. New identity server has been release 4.5.0, i guess you could try out it. This issue has been fixed on it [2]
[1] https://wso2.org/jira/browse/IDENTITY-1393.
[2] http://xacmlinfo.org/2013/09/13/getting-start-with-wso2-identity-server-4-5-0/