We are using an AS2 connection both for receiving and sending EDI messages. We configured the communication to be encrypted/compressed and signed.
Is it possible to track the EDI messages
on receive - after decryption and compression on send?
before encryption and compression?
With the built in tracking tools you can see the message in xml format. But it would be useful to have them in EDI.
The simple answer is yes. With BizTalk almost anything is possible and especially utilizing BAM with EDI - You should be able to view as native too. You can log the EDI message in X12 format... parse it and send to a database, email it... the possibilities are many. With Pipeline components you can log the message before anything happens to it or before the final send.
Related
Is there a re-try mechanism for all the calls(Services) initiated through Informatica to MarkLogic?
If yes, please provide the documentation or link for it.
By definition, retry of requests occurs on the client and not the server.
The MarkLogic Java API, for instance, supports retry of requests in cases where the payload is replayable. (Streaming payloads can't be retried, at least not without reconstructing the input stream.)
In this situation, what is the client? If, for instance, Informatica is a client of the MarkLogic REST API, then retry of the request would have to be implemented by Informatica.
I have an embedded device running BT5 with GATT server setup. On the server I have setup a service with various characteristics to allow a client (PC or Mobile Device) to adjust various parameters of the device by writing to the characteristics.
I would like, for the device to send a response back from the application level for each write. It's not clear to me what the recommended way would be.
I thought about having the client read or subscribe to a general status characteristic, but I want to make sure I am not missing an easier way to do this. I looked at the BT write with response command, but it seems the acknowledgement for that may happen lower than the application.
You should be able to use the Write Response as "application level response". I have not seen any Bluetooth stack where this response is sent at a lower level before the application has processed the request. The reason is probably because the application can even send an Application Error code instead of a Write Response, so it would be stupid to move the Write Response handling to a lower level. Even in Android (if you set up a GATT server) you send the Write Response from the application.
The situation is different with Indications, though, where the Bluetooth stack sometimes sends the Confirmation at a lower level than the application, before it even informs the application that an Indication has arrived, which I find a bit strange and makes Indications kind of pointless compared to Notifications.
I solved this using a Notification characteristic. The client first subscribes to notification events on that CCD, and then every command sent to the host/device is acknowledged by the host firing the notification. To better synchronize command-and-response, you could add an incremental command-id with every command, and have the command-id be part of the notification data that is sent back to the client.
However I implemented this because I needed a response after the device has processed the command, with the results sent back to the client. If all you want to know is whether or not the host has received the command, a Write-With-Response CCD is the way to go.
I looked at the BT write with response command, but it seems the acknowledgement for that may happen lower than the application.
Indeed, the Write-With-Response-Handler is almost always implemented on the BLE stack, not on application level. However I don't see why this would be a problem; you should get error reports by your BLE stack in some form when a Write-with-Response fails. If it's a blocking call it might even return a success-value.
Currently we have a Spring Integration application which accepts HL7 messages. The flow is as follows.
There is a message driven JMS inbound adapter which accepts the messages through ActiveMQ Queue.
Then the message goes through series of transformations and finally ended up in a service activator component to perform necessary business logic.
So far every thing looks good and recently the client requested that they want to have a acknowledgement for each message with the status. There can be two scenarios for a received message
Message executes successfully
Message fails with exception if the required criteria is not satisfied.
So we are thinking of implementing a acknowledgement mechanism which sends the acknowledgement back to the client through the above mentioned ActiveMQ queue or transmit via a tcp port.
Do we have any proven way/ patterns of doing these kind of acknowledgements? Is there any techniques which Spring Integration provides to achive this kind of scenario?
Appreciate your kind reply
Regards,
Keth
See the inbound gateway.
If the sender sets a replyTo header, the reply will be sent there; if not, you can configure a default replyTo destination.
In my scenario, a client sends HL7 via MLLP to my BizTalk two way receive port. BizTalk makes a web service call to an external service, receives the response, translates it to an HL7 ACK and returns it to the client, all in a synchronous transaction.
To make this happen, I have an orchestration that is directly bound to the message box, and the BTAHL7 party configuration is set to not route the ACK to the send pipeline on request-response receive ports. Basically I'm turning off the default ACK generation and generating a custom ACK from my orchestration. I have also added an additional filter to my orchestrations receive shape BTAHL7Schemas.ParseError == false so that the orchestration does not receive bad messages, in the event received messages don't match the schema.
Everything works great. In my testing, I am purposely sending bad HL7 messages. In this case, I get a suspending routing error report because no subscribers were found.
The reason for this behavior is pretty clear - I am not subscribing to messages that have parse errors. In the event of a parse error, I want the error ACK to go back to the client. I could allow my orchestration to subscribe to messages with parse errors, and just formulate an error ACK, but I don't have any way to return the actual parse errors in the ACK.
Normally, in an asynchronous architecture, I would turn on the "Route ACK to send pipeline on request-response receive port" and let the BTAHL72X receive/send pipelines handle it. Then the client would get the error ACK containing the error details.
So my question is, is there any way to get the receive pipelines original ACK and return it from my orchestration?
Yes, what you what you want is certainly doable. I don't have an HL7 project in front of my right now so my memory may not be exact but something like:
Uncheck "Reoute ACK to send pipeline..."
You will need a custom pipeline component to Promote BTS.InterchangeID on the disassembler output.
In your Orchestration, implement a Convoy correlated on BTS.InterchageID.
The Orchestration will then pick up the HL7 Message and the auto generated ACK.
Do you normal processing.
Decide which ACK to return, yours or the generated.
Return ACK to the TwoWay port.
*Non custom pipeline solution: *
In BTAHL7 Configuration Explorer Acknowledgement tab:
Set Acknowledgement type to Enhanced
Set MSH15 (Accept Acknowledgement Type) to NE.
Set MSH16 (Application Acknowledgement Type to ER
Turn on Route ACK to send pipeline on request-response,
It appears to get the behavior I want. Success ACKs won't be generated by the pipeline, letting my orchestration handle it, but application ACK errors will be generated (AR - Application Rejection), and routed to the send pipeline.
I'm sending messages between 1 dll and another, effectively posting messages onto the dll
input queue and receiving a messages back from the dll output queue.
These two dlls are very tightly integrated. DLL 1 is a producer,and DLL2 is the consumer.
I want to encrypt the messages before they are sent.
What would be the best approach?
Any help would be appreciated.
use the wcf bindings with message encryption enabled