I need to write automated tests for Enterprise Service Bus (ESB). When ESB is running it performs different scheduled operations including DB queries, SOAP and TCP calls, etc. Also it periodically checks whether some services are active and stops flows in case it is not.
So in my case there will be some problems:
some flows will stop because service is not responding
another flows will continuously run in negative scenariuos producing errors
Is it possible to have mocks continuosly running while executing tests using Citrus Framework?
How else can I overcome this problems with Citrus?
Please note that all server components in Citrus do only live while tests are executed. This is because Citrus automatically starts and stops the server components before/after the test suite. When Citrus is inactive the server components are stopped.
If you want to break these limitations please have a look at the citrus-simulator side project which is a complete standalone simulator for different message transport types (still in beta phase though).
If the limitation mentioned before is Ok for you then you can use a combination of endpoint adapters on the server components in your Citrus project. You could have a static endpoint adapter that always sends a positive response for incoming health check requests.
Please see the documentation on endpoint adapters: http://www.citrusframework.org/reference/html/endpoint-adapter.html
Related
We have spent several weeks trying to fix an issue that occurs in the customer's production environment and does not occur in our test environment.
After several analyses, we have found that this error occurs only when one condition is met: processing times greater than 3600 seconds in the API.
The situation is the following:
SAP is connected to a server with Windows Server 2016 and IIS 10.0 where we have an API that is responsible for interacting with a DB use by an external system.
The process that we execute sends data from SAP to the API and this, with the data it receives from SAP and the data it obtains from the DB of the external system, performs a processing and a subsequent update in the DB.
This process finishes without problems when the processing time in the API is less than 3600 seconds.
On the other hand, when the processing time is greater than 3600 seconds, the API generates the response correctly, and the server tries to return the response to SAP, but it is not possible.
Below I show an example of a server log entry when it tries to return a response after more than 3600 seconds of API processing. As you can see, a 995 error occurs: (I have censored some parts)
Any idea where the error could come from?
We have compared IIS configurations in Production and Test. We have also reviewed the parameters of the SAP system in Production and Test and we have not found anything either.
I remain at your disposal to provide any type of additional information that may be useful for solving the problem.
UPDATE 1 - 02/09/2022
After enabling FRT (Failed Request Tracing) on IIS for 200 response codes, looking at the event log of the request that is causing the error, we have seen this event at the end:
Any information about what could be causing this error? ErrorCode="The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)"
UPDATE 2 - 02/09/2022
Comparing configurations from customer's environment and our test environment:
There is a Firewall between SAP Server and IIS Server with the default idle timeout configured for TCP (3600 seconds). This is not happening in Test Environment because there is no Firewall.
Establishing a Firewall policy specifying a custom idle timeout for this service (7200 seconds) the problem will be solved.
sc-win32 status 995, the I/O operation has been aborted because of
either a thread exit or an application request.
Please check the setting of minBytesPerSecond configuration parameter in IIS. The default "minBytesPerSecond" is 240.
Specifies the minimum throughput rate, in bytes, that HTTP.sys
enforces when it sends a response to the client. The minBytesPerSecond
attribute prevents malicious or malfunctioning software clients from
using resources by holding a connection open with minimal data. If the
throughput rate is lower than the minBytesPerSecond setting, the
connection is terminated.
The reason I'm asking is I would like to use the out-of-proc mode, but I cannot install a service on each user's workstation, only on a central server. Is the communication between event source and listener service an ETW thing, or is there some kind of RPC I could use?
Yes, the out-of-process mode works by using ETW. All ETW events are system wide so the service just has to listen to ETW events.
ETW only works locally and does not offer a remote solution you could use. Your options are to install a service on each workstation, listen to ETW events (here or here) and forward them to your server with a RPC solution you build yourself. Using MSMQ comes to mind. Or have your application forward the events to your server directly so you don't need the service. Either way, you will have to build it yourself.
To add to Lars' answer, you could also log to SQL. There is a SQL sink you can use but like everything else, to get the most customized fit, you would build your own (or inherit from another class to give you a good starting point). Be careful though. Not all sinks are created the same. They all have their pros and cons. For example, with SQL and Azure sinks, you have to worry about high latency. The XML formatter doesn't write the root starting and ending node so it's not well-formed xml. Whatever reads that file would have to provide them. Good luck!
I have a C# application that enables users to write a test and execute it (client). It also supports distributed execution over multiple machines using a central server and agents on said machines.
The agent is practically a duplication of the original execution ability but it is in a standalone solution.
We'd like to refactor that because:
Code duplication.
If a user will try to write and execute on a machine that runs an agent, there will be a problematic collision.
I'm considering 2 options:
Move this execution to a service, that both client and agent will use. I mean a service that will run locally, not a web service.
Merge client and agent - we'll have no agent, but the server will communicate with the client as an agent instead.
I have no experience in working with services. Are there any known advantages/disadvantages to either options?
A common library shared by both client and agent sounds more appropriate to allow simple cases such as just using the client and avoid the overhead of having to set up an extra service locally.
It seems I am running into the Microsoft Distributed Transaction Coordinator (MSDTC) related issue.
SCENARIO
I am using TransactionScope and with in the single scope it hits two different databases on different servers (for instance, DB_A running Windows Server 2003 and DB_B running Windows Server 2008). One database is accessed using Entity Framework 4.0 and another using normal ADO.NET APIs.
When I run the application from my development machine (running WinXP) it commits and rollbacks both the connections accurately. But when I run the application, deployed on another server (for instance WAS_A running Windows Server 2003) it commits correctly but in case of exception is doesn't roll back the database activities on both the servers.
I thought it would be the MSDTC configuration issue on the WAS_A. So I went to the MSDTC -> Security Configuration and checked all the available options (as I did previously on other machines). But still I am facing the same issue.
Looking for your expert advices. :)
I believe that you need to look into Enabling Transaction Flow. Specifically, take a look at how one may error and the other complete as described in TransactionScope and WCF Services:
an error in a second WCF service call was NOT rolling back the changes made in a previous WCF service call...
In order to create an ambient transaction in your client and ensure that it is used by your WCF services...
The article then details the following steps:
Configure Your Binding with transactionFlow
Decorate Your Interface with [TransactionFlow(TransactionFlowOption)]
Decorate Your Method with [OperationBehavior(TransactionScopeRequired)]
Optionally update your Connection Strings with Transaction Binding*
*Note: This is optional in my opinion.
I have a solution that has a self hosted WCF Service. That service connects to EF and can read and write just fine.
In the same solution I also host an NServiceBus endpoint. It gets event from a separate running solution.
When I run the NServiceBus project (by itself) it seems to be working fine, until I try to query my database. When I do that I get this EntityException:
The underlying provider failed on Open.
The inner exception is a TransactionException with a message of:
The partner transaction manager has disabled its support for remote/network transactions
Both my NServiceBus and WCF Service projects are using the exact same configurations and EF Projects. I don't get why one is failing and the other is not.
I did some Googling and came across this page: http://msdn.microsoft.com/en-us/library/aa561924%28BTS.20%29.aspx that showed me how to setup MSDTC, and I did it on my client machine. But it had no effect.
I also found this question that says it needs to be set: NServiceBus: System.Transactions.TransactionException: The partner transaction manager has disabled its support for remote/network transactions. But it does not say why or where.
Do I need to setup MSDTC on my db server? If so, why? What is MSDTC?
Why does running from an NServiceBus hosted process cause this error?
UPDATE: I found this link that helped me understand what DTC does. It also showed me how to turn it off if needed:
using (TransactionScope sc=new TransactionScope(TransactionScopeOption.Suppress))
YourDatabaseHandler.SaveMyStuff(whatever);
Though it sounds like it is a good thing in many situations.
Since NSB is using a transactional queue, your going to be participating in a distributed transaction. This means that each machine participating will have to vote on whether or not to complete a transaction. This is done via the Distributed Transaction Coordinator(MSDTC). This will have to be running on both machines(and if you are using other DBs like Oracle there is an additional service). To manage MSDTC, go to Component Services -> Computers -> My Computer -> Distributed Transaction Coordinator -> Local DTC. Right clicking on that node you will find all the configuration including security.