I have a solution where I receive a message over a two way receive port, which an orchestration subscribes to. The orchestration then calls a web service and returns a translated form of the web service response to the receive port.
If I run a completed service instances query in the BizTalk administration console I can see the receive ports receive pipeline, the orchestration, the web service transmit and receive, and the receive ports send pipeline all completed. From the results of that query it is not possible to correlate each service instance together. I can correlate the receive pipeline and send pipeline of the receive location because they have the same service instance, but I can't tell which orchestration service instance and which web service instance correlate to those...
This may not be exactly what you want, but if you right click the orchestration service instance and select "Message Flow", find the outbound message that calls the web service and click on the pipeline link, that will give you the message flow for that service (the pipeline), which includes the service id.
Right click orchestration, select "Message Flow".
Click on the link to the send part of your web query.
This will give you the service details (the pipeline)
Related
There is a server application (ASP.NET Core (gRPC service)) and a client application running on another PC (WPF).
One of the functions of the gRPC service is to send screenshots to the client application, but it has to be run as a Windows service, so I can't get screenshots directly from the service to the client application.
Question: how to implement an "agent" application running on a remote computer where the service is, but in a user session to get screenshots through it and then pass them to the client?
As I understand it is possible to do it with the help of IPC, but I can't understand the details of implementation, how can I call from gRPC service to the agent to make a screenshot, return the result (as an array of bytes) to the service and it sends it to the client...
I am planning to use vaultTrack method to track the changes in state object.Once I capture the events at client level am planning to store those data in offline DB or invoke another API. Will there will be any challenge in this implementation. As per my understanding RPC client library will be listening all the time for state changes and also it handles the incoming RPC calls from external parties . Will it slow down the performance. How exactly vaultTrack method working internally .
Hi I don’t see any challenge in your implementation.
In Corda we use Apache Artemis for RPC communication. The Corda-RPC library must be included on the client side in order to connect to the server.
Internally this works like this -
At startup Artemis will be created on the RPC client(client side) and RPC server (within the corda node), client and server queues are created, and sessions are enabled/established between client and server. The Corda-RPC library contains a client proxy, which translates RPC client calls to low-level Artemis messages and sends them to the server Artemis instance. These RPC requests are stored on the server side in Artemis queues. The server side consumer retrieves these messages, approprite RPC calls are made, and an acknowledgement is sent to the client. Once the method completes, a reply is sent back to the client. The reply is wrapped in an Artemis message and sent across by server Artemis to the client Artemis. The client then consumes the reply from client Artemis queue.
The client proxy within the the Corda-RPC library abstracts the above processes. From a client perspective you should only create the proxy instance and make the RPC calls.
I would urge you to use the Reconnecting Client. You can read more about this in a blog which I have written.
Also please read the last part in the blog which talks about how to handle reconnection/failover scenarios.
I'm troubleshooting a very generic BizTalk error that is resulting in transmission/routing failures (see below). Even though my receive location is started, it does not appear to be listening for anything. When I run a query for all Activation Subscriptions, the receive port is not showing up in the list. I cannot figure out why it is not subscribing to my send ports.
Error:
The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.
One Way Receive locations don't have Active subscriptions, only Orchestrations, Send Port Groups and Send Ports do. For a One Way your Send Port should be listening to your Receive Port rather than your Receive Port to your Send Port.
If it is a Request / Response port then see section below
One Way Receive Location
A Receive Location picks up from an external location and it goes via the associated receive port and publishes into the message box.
As your error clearly indicates that the message has been published to the message box the receive port is obviously working (although maybe not correctly) or it has been published back from a send port or orchestration.
What you have to check is
The context properties on the suspended message using BizTalk Administrator
The Subscription belonging to the Send Port / Orchestration that you expect to handle the message
Compare the two and see what does not match
The possibilities are
Your Receive Port is not promoting the properties you expect. Check the receive pipeline and promoted properties on the schema. If your pipeline is set to pass thru, only some of the standard promoted properties will be there and no message type or promoted properties from the schema, if you need those promoted properties set your pipeline to XMLReceive or a custom pipeline with either a XML Disassembler or a Flat File one.
Your Send Port / Orchestration are not in an Enlisted state, if they aren't enlisted then no subscriptions are published for them. Enlist or Start them.
Your Send port/Orchestration subscription is wrong (does not match the message context properties), correct them so that they match.
Request/Response Receive Port
For a Request Response Receive location/port it creates an Instance Subscription for a message which looks for BTS.EpmRRCorrelationToken (which contains details of the hostinstance, port and a GUID) and BTS.RouteDirectToTP == True
It works out of the box if you either have a Request/Response Send port subscribing to a Request/Response receive port, or if you use a Request/Response Port in an Orchestration. If you use separate Receive Send Ports in the Orchestration you need to set the above properties in your message construct shape manually.
See Messaging-only request-response correlation
Thanks for the clarification on receive locations. I'm new to BizTalk, as I have recently inherited the role of supporting it. The problem ended up being an incorrect reference in an endpoint behavior extension in the receive location.
I have created a BizTalk application to connect to VSO Rest API to fetch or create work items.
I have configured a wcf-webhttp adapter for calling the rest API.
Before configuring the adapter, I have tested the API with console application and getting the results with same URL.
While running the application I am getting following error:
The adapter failed to transmit message going to send port "SendPort" with URL "the URL". It will be retransmitted after the retry interval specified for this Send Port. Details:"System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at https://xxx.visualstudio.com/defaultcollection/_apis/wit/workitems/2
connected host has failed to respond 23.98.150.230:443
But when I paste the URL in the browser I am able to see the result returned by API in the browser.
What could the issue be?
In Microsoft BizTalk Application when exception occurred then Services or port will goes to in suspended mode and need to manually start application or port.
What i want is when any exceptions occurred during message processing should send one email alert to system administrator and details of exception should be stored in separate database for further process.
Anyone have any better suggestion how we can do it.
Regards,
Rakesh
To handle the message failure secnario see using Failed Message Routing. As far as monitoring ports when they shut down you can either use MOM (expensive) or write a script to do what you want. There are many posts here in stackoverflow that address this... here is one such post.
To get an email alert sent for any messaging failures (i.e., a failure in a send or receive port)
For each send or receive port for which you want to track failures, edit the port properties and check the box for "Enable routing for failed messages"
For send ports, you'll find this option under "Transport Advanced Options".
The option for receive ports is under the General section of the port properties.
Create a new Send Port (perhaps in a separate "Exception Handling" BizTalk application) that uses the SMTP adapter to send the emails.
To send out all failed messages using this new port, create a filter on the send port with the Property ErrorReport.ErrorType == FailedMessage. That will evaluate as true for all messages that error on a send or receive port for which you enabled Failed Message Routing.
If you need to route messages differently, at a more granular level, then have a look at the properties on the Failed Message Routing page referenced by ChrisLoris.
To track exceptions for failed messages in a separate database, I would start with the Microsoft BizTalk ESB Toolkit Exception Management Framework, as it includes a database for this purpose and the mechanism to push exception/failed message data into that database (build atop Failed Message Routing). It even includes a web site to enable users to interact with the failed messages, which you can customize as you see fit or throw away altogether.
The instructions to install the just the Exception Management part of the ESB Toolkit are available at http://msdn.microsoft.com/en-us/library/ee250099.aspx. Microsoft's guide to using the ESB Exception Management is worth a review too and is here.