I'm on a QA environment, and can talk to the BizTalk Admin tomorrow. Apparently, I'm the first person to call a BizRule from an orchestration, and the orchestration is giving error:
Inner exception: The type initializer for 'Microsoft.RuleEngine.RuleEngineCache' threw an exception.
I checked, and the Rules Engine is configured on this machine. But the "Rule Engine Update Service" was not running. I tried to start it, and get this error in the "Services" tool:
"The Rule Engine Update Service service on Local Computer started and
then stopped. Some services stop automatically if they are not in use
by other services or programs."
I checked the event log, and for each time I tried to start it, I see this:
Service could not be started. :
System.Reflection.TargetInvocationException: Exception has been thrown
by the target of an invocation. System.InvalidCastException: Specified
cast is not valid.
Any ideas what I can do? I have admin privileges on the machine (BizTalk 2013/R2).
Our BizTalk Admin corrected the CacheEntries using RegEdit. The one on the right was the other server in the group that was working.
Related
I've been running component tests in a .NET 5 application using LightBDD. In each test we bring up an instance of an ASP .NET core "application" that we connect to via grpc. At the end of each test we shut down the "application".
This "application" starts a connection to a Postgres instance (in the tests this is constantly running locally in Docker and is not restarted between tests) and then closes it at shutdown.
In a sequential run of 30 tests I got the following error twice (separated by about 5 successful tests):
Postgres exception: 42501: must be a member of the role whose process is being terminated or member of pg_signal_backend
I haven't been able to reproduce it since. Does anyone know what potentially could have caused this intermittant issue?
You get that error if you are trying to cancel a transaction of a different database session or terminate such a session, but that other session is with a different database user.
The error message informs you what privileges you need to do that: you either have to be the same user (or a member thereof), or a member of pg_signal_backend or a superuser.
We have Websphere Message Broker v8.0.0.3 on Redhat Linux env, and we encounterd the following runtime error message:
BIP2057
Execution Group <insert_1> could not be started: broker name <insert_2>; UUID <insert_3>; label <insert_4>; Pub-Sub server <insert_5> (1=Yes, 0=No).
The situation is that one of the execution groups stopped (without any trace/log about it) and the wmb could not auto start with the BIP2057 error.
the weird part occurs when another EG restarted (unlinked reason to the first problem, because of some applicative errors) and then the first EG "took its place", started successfully, and now the second EG could not start for the same reason.
We have checked for user permissions or the logs without any success in identifying the problem.
Any help would be much appreciated.
Run the following service IBM MQSeries if it's not running already:
C:\Program Files (x86)\IBM\WebSphere MQ\bin\amqlsvc.exe
If it gives an
exception of Access Denied, your user must not be having rights to
log on.
Another possible resolution can be by restarting the
DataFlowEngine.exe process.
If none of the above scenarios fulfill the need, restart the system.
Looking in the BizTalk Admin Console under tracked service instances and I can see that the default XML Receive pipeline starts, however it never completes. It remains at status "started" with the error code set to -1061153241. In tracked message events I can see the pipeline receives the message, however i can't see a "send" event type and it looks like the message is not sent to the MessageBox for the waiting orchestration to pick it up. My orchestration never gets initiated. There are no error messages in the event log, no suspended service instances, just the tracked service instance showing starting and not completed with the error code specified above.
I managed to resolve this issue. I had previously just GAC'd a dll and didn't update it as a resource in the Admin Console. Once I updated the Admin Console with this resource and restarted host instances the error went away. Thanks.
I've got a new production computer and installed my BizTalk app on there. The problem is that I don't see any messages in the event log, nor from my BizTalk app or BizTalk Server itself. The only message that appears in the event log is the following:
The following BizTalk host instance has initialized successfully.
BizTalk host name: BizTalkServerApplication
Windows service name: BTSSvc$BizTalkServerApplication
The source of that message is BizTalk Server. And no messages at all, even no logs about errors which I suppose already took place.
Just a quick thought incase you are still having problems.
I tried to write to the event log with a source type that didnt already exist and my BizTalk Host user account didn’t have permissions to create a new source type. This meant I never saw the entry in the event log.
E.g. (from example #Bill Osuch)
System.Diagnostics.EventLog.WriteEntry("MyBiztalkApp", "oh i did something");
Make sure either the MyBiztalkApp source exists or that your user has permissions on the event log to create it.
Also, if you have a lot of messages going through BizTalk you will probably want to implement your own logging so your event log doesn’t fill up. We used Log4Net for our implementation and a database to store messages.
If you're not getting any errors (suspended messages) as the messages process, you're not going to see anything in the app log. You could try adding an Expression shape to your orchestration and manually writing out some debug info:
System.Diagnostics.EventLog.WriteEntry("event type", "whatever...");
Does your application actually use the BiztalkServerApplication host? Check in the Biztalk Administration Console if all the host instances are indeed running. Is your application fully started? Messages are "put on hold" if your receive location is disabled for example.
To check this functionality, write to event log after every operation or shape in BizTalk orchestration.
Scenario-
Suppose you have to assigned a value to xpath of node in a map after transformation so in message assignment shape after you assign some value, you can write eventlog to admin console.
Ex. Suppose we have already initialized - "orderType" as "PO" in our expression shape and now we have to assign the value of "orderType" to the xpath of a node in our map then-
Shape- MessageAssignment(Under constructMessage Shape after transformation of map)
xpath(msgGetOrderReq, "/[local-name()='CustomerOrders' and namespace-uri()='http://example.com/EAI/IEmployee/v1.0']/[local-name()='ordertype' and namespace-uri()='http://example.com/EAI/IEmployee/v1.0']") = ordertype;
Next to this we want to print this information on the admin console so we need to write:-
System.Diagnostics.EventLog.WriteEntry("msgGetOrderReq", ordertype, msgGetOrderReq);
Build the project, Deploy and GAC it. Restart the host instance. Run the orchestration, process something and now you will be able to see the logs in admin console.
Regards
Mayank
I am getting below error, when i am trying to resume Suspended(resumable) orchestration instance.
Scenario: Request went thourgh DB2 Static solicit - Response port, and it got failed because of access permission denied. I can see two instances suspended in the admin console one is related to port and another one is related to orchestration. After fixing the credentials, suspended port instance got resumed but the orchestration one is keep on failing.
Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'Orchestration name'.
The service instance will remain suspended until administratively resumed or terminated.
If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.
InstanceId: ca927086-465d-40e8-93fe-c3a0e4c161f7
Shape name:
ShapeId:
Exception thrown from: segment -1, progress -1
Inner exception: An error occurred while processing the message, refer to the details section for more information
Message ID: {96B72521-9833-48EF-BB2F-4A2E2265D697}
Instance ID: {F6FBC912-C9DC-489C-87F3-103FA1273FDC}
Error Description: The user does not have the authority to access the host resource. Check your authentication credentials or contact your system administrator. SQLSTATE: HY000, SQLCODE: -1000
Exception type: XlangSoapException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: Void VerifyTransport(Microsoft.XLANGs.Core.Envelope, Int32, Microsoft.XLANGs.Core.Context)
The following is a stack trace that identifies the location where the exception occured
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.VerifyTransport(Envelope env, Int32 operationId, Context ctx)
at Microsoft.XLANGs.Core.Subscription.Receive(Segment s, Context ctx, Envelope& env, Boolean topOnly)
at Microsoft.XLANGs.Core.PortBase.GetMessageIdForSubscription(Subscription subscription, Segment currentSegment, Context cxt, Envelope& env, CachedObject location)
at Microsoft.XLANGs.Core.PortBase.GetMessageId(Subscription subscription, Segment currentSegment, Context cxt, Envelope& env, CachedObject location)
at (StopConditions stopOn)
at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Any thoughts how to fix this?
Creating the above scenario using samples:
Go to BizTalk
samples/orchestrations/consumeWebservice
folder, install the
ConsumeWebService application and
publish POWebservice to IIS.
Change IIS Directory security
permissions for POWebservice, remove
anonymous or any other access.
Now drop the message you will see
suspended messages because of HTTP
status 401: Access Denied, then give
access to POWebservice either
anonymous or Windows.
Then resume
the suspended instances, one will
get disappear but
another(orchestration) one wont.
The orchestration will continue to fail with the exception because when it was suspended, the last persistence point was the receipt of the exception. This means that the orchestration will re-start (when resumed) and re-throw the exception.
Here's at article discussing some points at which orchestration state is persisted to the database: http://blogs.msdn.com/b/sanket/archive/2006/11/12/understanding-persistence-points-in-biztalk-orchestration.aspx
You can manipulate this to some extent in your orchestration design, as Richard Seroter discusses here, but generally you would do better to use failed message routing, enabling you to handle the failed messages, and terminate the failed orchestration instance.
Please correct me if I'm wrong, but is this not just normal biztalk behavior? I am not 100% sure so please let me know if this is wrong:
The outbound messaging instance was suspended because the credentials the port was using to connect to to the DB were wrong.
This caused the orchestrations making these calls to also suspend.
The suspended message instance was resumed and was processed correctly because the problem was fixed. So the call was made to the DB.
However, the orchestration instance may not be able to resume because when resumed it found itself at the most recent persistence point and the original error which was delivered back from the send port is still available to the orchestration, causing it to re-suspend.
In the error message, it actually says "If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception."
If you want to handle this sort of thing you could make the call to the database atomic. That way the orchestration will not persist itself at the point of making the DB call. If the orchestration then suspends it will resume at a point before the DB call is made, and will make the DB call as normal, which should succeed this time because you have fixed the original issue.
The only problem with this is if your DB call cannot be executed more than once with the same data without bad things happenning (is not idempotent).
I am not 100% on the above explaination. Please point out if my understanding is incorrect.
this scenario not treated by Microsoft Biztalk = Middleware FAIL.
you have to solve this at the orchestration design stage up front...
http://seroter.wordpress.com/2007/01/02/orchestration-handling-of-suspended-messages/