I'm trying to initiate the execution in a remote machine for which i want to get the execution status of a specflow scenario when executed using Command Prompt.
Note: I'm achieving this using TCPClient & TCPListener approach.
In this approach, i would like to pass the scenario tag like testcase id as - #1234 via TcpClient and in TCPListener i will listen to that tag number and will pass down such that i will execute via command prompt.
Here, i would like to get the Scenario execution status like Pass, failed, pending... such that i can pass it back to TcpClient and i can complete end to end testing...
Thank You in Advance.
Since you are running the testing using command prompt you can check for the error level. Following link might be helpful for the same:Batch Files - Error Handling
Related
I have .net 6 isolated function docker container that works locally but not in azure. The docker file copies the build output binaries to the home/site/wwwroot directory of the container based on the image mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated6.0.
When I look at the live log stream I can see
the configuration is setup correctly as far as I can see but I don't have full access. its setup as dotnet-isolated and functions version 4. I can see its pointing at the right docker image.
I'm not sure what else to check troubleshoot why it doesn't start properly. Are the files in the correct location in the docker file? does it need anything else that I have missed?
Any advice will be greatly appreciated.
Thanks
Thanks, i should have mentioned that this is for a timer trigger only so there is no http triggers
In the Azure Functions:
For the Http Triggers, response comes in Http Status Codes.
For Timer Triggers, failed responses can be thrown in the form of exceptions but not the status codes.
I found an article in dontcodetired site where the author mentioned that we can write the status code manually which returns automatically during some situations which is taken care of by Azure Functions Runtime.
One of those situations is returning the status codes automatically in the case of failed operation like without the exception, function completes the execution without proper result which is a kind of internal server problem- it means the request of (any trigger type) is processed/succeeded but without proper response or operation result.
While executing runAppInBackground() for Android application through Appium the app gets restarted but when executed the same manually couldn't be able to reproduce the same. I Would like to deep dive into implementation of a runAppInBackground() method to reproduce the same issue in a manual way.
You need to look behind the code of runAppInBackground
From java client side (your test code) perspective, it is a single call to Appium server:
POST "/session/:sessionId/appium/app/background"
If you continue looking into where its implemented on server side, you finish with appium-android-driver function.
In short what it does:
Get current activity and package
Press physical Home button
Wait for time you provided as argument (seconds)
Bring up back in focus based on different conditions; from the code you can understand what activity is being started
Basically its a sequence of adb shell commands, that you can run from terminal.
My guess is that step 4 you did manually may differ from what Appium is doing: different activities/arguments for activity been called
We are using Spring XD for executing some batch jobs and considering to use Spring Cloud Dataflow. For this I wanted to remote debug a execution of a Task and I was not able to make it working.
I tried to export the following environment variable before the SCDF server is started:
spring.cloud.deployer.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Also tried to pass as argument in the GUI while invoking the task:
app.<appname>.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Nothing seems to be working.
I'm able to debug the composed-task-runner launched by SCDF using the listen debugger mode, this will also work for your task as well.
Run Debugger in your IDE in listen mode on port 5006. (this project's classpath should have composed-task-runner sources, put break point some where )
Run SCDF with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 option, attach debugger to the SCDF process in your IDE on port 5005 (attach mode).
Put breakpoint at this line :
String javaOptsString = getValue(deploymentProperties, "javaOpts");
in JavaCommandBuilder class (for spring-cloud-deployer-local v.1.3.0.M2 it's line #83).
Launch your task - debugger stops at breakpoint.
Step Over once in your IDE, the value of javaOptsString is null now. Using IDE, set the value of javaOptsString to
-agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y
Press Resume in IDE.
Your breakpoint set in #1 should be hit in few seconds.
If you know how to pass javaOpts as deployment properties of your task - you will be able to debug in listen mode without this nightmare ;-). I've not found a way to escape = and , characters in the -agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y javaOpts deployment property.
We are working on an improved solution for the local-deployer - you can follow spring-cloud/spring-cloud-dataflow#369 for tracking purpose.
There is, however, the following option that exists to aggregate all the application logs into the server console directly, which might be useful while in active development.
stream deploy --name myStream --properties "deployer.*.local.inheritLogging=true"
Finally I was able to remote debug a composed task or regular task. Follow the below steps:
In scdf UI go to tasks and click on the definition section
Click play button (invoke) on the task/composed task that you want to invoke.
On the launch task page define your task arguments
Add the following properties by clicking 'Add Property' button:
- deployer.composed-task-runner.local.debugPort=12103
- deployer.composed-task-runner.local.debugSuspend=y
Now launch the task
You can now see in the log that when the composed task's java process is launched it is called with the debug parameter.
If you want to control the heap memory or any java options you can do by adding the following property:
deployer.composed-task-runner.local.javaOpts=Xmx2048M
Note that 'composed-task-runner' is the name of the App (Not the name of the task).
I have a Windows service written in VB.NET 2.0 which connects to an IBM AS/400 server. Queries work fine, but when I try to do something like deleting a spool file, I get errors. For example:
CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)
Running this command with ExecuteNonQuery yields:
CPF3342 - Job not found 083064/ARUSER/POASYNCMON
However, if I run that same command locally in AS/400, it works just fine. We already checked permissions. What else could be causing the command to fail this way? How can I get more information about the error, or go about troubleshooting this?
EDIT: This problem (and a lot of other ones) appeared when we migrated our server (where the .NET service runs) from Windows Server 2003 to Windows Server 2008.
How can I get more information about the error, or go about troubleshooting this?
The first thing is to verify that the IBM AS/400 server [what OS Version Release and Modification level, Technical Refresh (TR) level (if instead IBM i), Cumulative PTF level were all omitted.?.?] used for the connection is the same server used to perform the command-line invocation; i.e. on the server where the command-line invocation will be made to verify the command is functional, find the active server job in which the CPF3342 is still visible in the log.
The second thing to do is to get the spooled joblog showing the full details of the CPF3342 [and possibly any preceding message(s) that might be related]. If for example the message is not actually that message or is not sent by the expected program QSPCPYF, then immediately the direction of investigation probably would change. What is shown is apparently what is presented at the client, not what came from the server joblog; the USEnglish formatting I believe is "Job &5/&4/&3 not found." for which the formatting "CPF3342 - Job not found &5/&4/&3" is suspect.
To ensure the most appropriate comparison to the request made from the client:
• the local user that is signed-on to perform the same request should be the same user as the Current User of the active job found to be servicing the client request
• the local user should establish the same System Library List as the active job found to be servicing the client request
If such an incident recurs or even if the same incident persists, then verify the once again the re-create is still possible using the same interface [i.e. the condition\failure persists] and again verify the command-line request is successful [i.e. the circumvention is confirmed, that the same request is possible to be performed at the command-line]; and according to my earlier comment, first ensuring the same server by finding the active job that logs the CPF3342. Immediately afterward:
• Collect a job trace for the Copy Spooled File (CPYSPLF) request; for the failing case, review for any exception\interrupt conditions [with or without a message as accompanying trace data] that precede the program flow for the issuance of the msg CPF3342.
• Review the audit log for any T-AF or anything odd\unexpected at very close to the time of the failing request; expansive auditing should have been established since before the connection to the server.
• Contrast those data collections of the failing case with the same data taken from the successful processing.
Although the symptom [as lightly described, without the full joblog] the possibility of command-exits seems remote, the trace would reveal if the command in either scenario were intercepted by the Command Exit points; these can be reviewed separately [rather than looking in the trace] for any Exit Program, using the Work With Registration Information (WRKREGINF) to review any QIBM_QCA* entries in the repository for what exit programs might impact the CL Command request. But IIRC the trace-data shows which command was invoked, so the trace would also reveal if the unqualified command requests resolved to different *CMD objects.
I have a few Windows Services written in C# that I have setup to support being run from the command line as a console app if a specific parameter is passed. Works great but I would love to be able to detect whether the app is being run by the service control mananger or from a command line.
Is there any way to tell at runtime if my app was started by the SCM?
Environment.UserInteractive will return false if the process is running under the SCM.
The SCM will call your OnStart method, so you could mark that event and make sure when you run from the command line, you don't call OnStart. Or, you could check the startup parameters to see how the application was started.
In C the function StartServiceCtrlDispatcher() will fail with ERROR_FAILED_SERVICE_CONTROLLER_CONNECT. This is the best way in C, wonder if C# exposes any of this?
ERROR_FAILED_SERVICE_CONTROLLER_CONNECT
This error is returned if the program is being run as a console application rather than as a service. If the program will be run as a console application for debugging purposes, structure it such that service-specific code is not called when this error is returned.