I designed a customized reporting template, I am wondering how to put the report block inside a conditional statement.
For Example:
If the Below code execute succesfullt and status is Failed, Then how to capture it inside my report.
http()
.client(todoClient1)
.receive()
.response(HttpStatus.OK)
.validate("$.statusCode", "202");
Thanks In Advance
BJ
Your custom reporter should implement TestListener interface that is called with failed test state when something went wrong during the test. The failed state includes the failure stack trace as well as the exception cause. Also the listener is provided with test case object that provides the method getLastExecutedAction(). This is the last executed action that caused the failure.
Also the conditional block action provides direct access to the nested actions in the conditional container for detailed customized reporting then.
Related
I've stumbled upon a problem when using some more complex argo workflows with initialization and clean-up logic. We are running some initialization in one of the initial steps of the workflow (e.g. creation of some resources) and we'd like to perform a clean-up regardless of the status of the workflow. onExit template seems to be an ideal solution (I think that clean-up is even mentioned in argo documentation as predestined for tasks of the onExit template).
However, I haven't found a way yet to pass some values to it. For example - let's say that in the initialization phase we created some resource with id some-random-unique-id and we'd like to let the onExit container know what resources it needs to clean up.
We tried the outputs of some steps, but it seems that steps are unknown in the onExit template.
Is there a built-in argo mechanism to pass this kind of data? We'd like to avoid some external services (like key-value storage service that would hold the context).
You can mark output parameters as global using the globalName field. A global output parameter, assuming it has been set, can be accessed from anywhere in the Workflow, including in an exit handler.
The example file for writing and consuming global output parameters should contain all the information you need to use global output parameters in an exit handler.
https://github.com/argoproj/argo-workflows/blob/master/examples/global-outputs.yaml
Please share if you found a cleaner solution.
I see this workflow example for exit handler with parameters, which may resolve your issue: Exit Handler with Parameters
One method I found was to add steps to the template I want to call the exit template on, and call the exit template as the last step so I can access steps variables. I changed the original template to an inline template so the structure does not change too much, just involves adding the last step call to the exit template. Unfortunately, this does not utilize the actual onExit method.
Inline steps template example
1.https://sourcegraph.com/github.com/argoproj/argo-workflows/-/blob/examples/exit-handler-with-param.yaml?L21
2.https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/steps-inline-workflow.yaml
For a project I'm trying to select the right output if a parameter of the created agent is true. The agent is created in the main but goes into a different agent for the selection of the output. If I use a select in the main and use the statement for the parameter as condition it works fine. Whenever it enters the agent and I use the same statement it gives an error (Description: product1 cannot be resolved or is not a field. Location: testCase5/Transport/selectOutput - SelectOutput).
I tried using different conditions like main.agent.product1 . Can't seem to solve the issue. I know that it has to do something with declaration probably but I'm clueless at the moment.
//for the condition that works if I put the selectOutput in the main
agent.product1
//for the condition in the agent I tried the same but didn't work. also tried
main.agent.product1 // Gives the same error but for (Description: agentcannot be resolved or is not a field.)
(Main)agent.product1
//And a few more
In AnyLogic each block of a project flow (regardless if from the process modeling library, the pedestrian library or another) has the type of Agent that is flowing through it defined in its properties. You can find this setting as Agent type in the block's properties under Advanced.
If you fail to set this correctly (meaning this setting equals the type of Agents you let flow through it), it will still flow through, BUT: you cannot access the specific properties of the Agent type.
That said, usually you do not even have to think about, because AnyLogic has an automatism there: The first block of your process flow, typically a Source-block or a Enter-block is the only block where you have to make the correct setting, all attached blocks get it then automatically!
However this does not work when:
You have separate flows (eg. you leave one flow through an Exit-block and enter another by an Enter). You'll manually have to put the correct setting also for the first block of the second process flow.
Your process flow is continued inside of another Agent/Custom Block, as in your example. AnyLogic doesnt realize the process flow inside your custom block is logically connected to the outside process flow in main. You have to specifiy manually again the Agent type flowing through in the first block of your process inside your Custom Block.
I'm confused when to use
var flow = protractor.promise.controlFlow()
in protractor scripts and also I can see a method called execute method flow.execute().
Can Any one give me some example and elaborate above statement
You shouldn't normally need to use the controlFlow yourself unless you are trying to add some asynchronous code into the middle of other webdriver operations. You would basically have to wrap that asynchronous code inside of a promise and the pass that promise/function into the flow.execute(). Here is a good link with more information about Control Flow in WebdriverJS
https://github.com/SeleniumHQ/selenium/wiki/WebDriverJs#control-flows
I am trying to use ReportViewer1.PrintDialog() instead of ReportViewer1.Refreshreport()
I mean to take my report to printer, instead of viewing it.
But when I run the code, it generates error.
The error is
Operation is not valid due to the current state of the object.
Please advise what is the problem?
Thanks
Furqan
It might be because the report is already in the process of rendering when you call PrintDialog(). You have to wait for the rendering to complete in order to avoid this error. You can use the RenderComplete method to detect when the report is done rendering and it is safe to call PrintDialog().
I want to implement a solution in my workflows that will do the following :
In the workflow level I want to implement a Fault Handler that will suspend the workflow for any exception.
Then at sometime the instance will get a Resume() command .
What I want to implement that when the Resume() command received , the instance will execute again the activity that failed earlier ( and caused the exception ) and then continue to execute whatever he has to do .
What is my problem :
When suspended and then resumed inside the Fault Handler , the instance is just completes. The resume of course doesn't make the instance to return back to the execution,
since that in the Fault Handler , after the Suspend activity - I have nothing. So
obviously the execution of the workflow ends there.
I DO want to implement the Fault Handler in the workflow level and not to use a While+Sequence activity to wrap each activity in the workflow ( like described here:
Error Handling In Workflows ) since with my pretty heavy workflows - this will look like a hell.
It should be kinda generic handling..
Do you have any ideas ??
Thanks .
If you're working on State Machine Workflows, my technique for dealing with errors that require human intervention to fix is creating an additional 'stateactivity' node that indicates an 'error' state, something like STATE_FAULTED. Then every state has a faulthandler that catches any exception, logs the exception and changes state to STATE_FAULTED, passing information like current activity, type of exception raised and any other context info you might need.
In the STATE_FAULTED initialization you can listen for an external command (your Resume() command, or whatever suits your needs), and when everything is OK you can just switch to the previous state and resume execution.
I am afraid that isn't going to work. Error handling in a workflow is similar to a Try/Catch block and the only way to retry is to wrap everything is a loop and just execute the loop again if something was wrong.
Depending on the sort of error you are trying to deal with you might be able to achieve your goal by creating custom activities that wrap their own execution logic in a Try/Catch and contain the required retry logic.