I am building an integration that should fetch a zip-file from SFTP and save it as XML on disk. I have got everything working except the unzip-part...
The integration looks like this.
Receive location polls the SFTP, and in the receive port "Inbound maps" I have provided a mapping schema (converting the txt-file in the zip file to XML).
Receive location: polls the SFTP, custom receive pipeline.
Custom pipeline: In Disassemble first the unzip-component from BizTalk Utility pack ( BizTalk Server 2020 – 20 days, 20 posts: Unzip File Pipeline Component for BizTalk Server 2020) and then the flat file disassembler. The document-schema here matches the source-schema in the mapping.
Send port: Save file on disk.
The problem is that when I run the integration, the file is picked up from the SFTP and the file is indeed unzipped but the send port saves the content from the original file to the send-location. It is as if the mapping is never executed.
But if I remove the unzip-component in the custom pipeline and manually unzip the file and upload the content (.txt-file) to the SFTP everything works fine.
As per Sandro Pereira's instruction no configuration is needed, so I don't really understand why it is not working.
Receive Pipelines - Disassemble stage (Microsoft.com)
If this stage contains more than one component, only the first component that recognizes the message format is run. If none of the components within the stage recognize the message format, the message processing fails.
So you can't have both in the disassemble stage of the pipeline and have them both execute. Move the Unzip to the Decode stage of the pipeline.
Related
I have a pipeline that is working for a file receive location. This pipeline accepts a csv file and maps it to an XML.
I'm now trying to setup a new email receive location using the same port, pipeline and pipeline settings.
Shouldn't biztalk ignore everything but the attachment if I set the body part index equal to 2? And then it should place the attachment in the pipeline just like with the file location, then the pipeline would output an XML file.
Error:
Microsoft.XLANGs.Core.PersistenceException: Exception occurred when persisting state to the database. ---> Microsoft.BizTalk.XLANGs.BTXEngine.PersistenceItemException: A batch item failed persistence Item-ID 72fbeba9-6bfe-48e0-a0e6-ca5bbd191aa1 OperationType MAIO_CommitBatch Status -1061151998 ErrorInfo The published message could not be routed because no subscribers were found. . ---> Microsoft.BizTalk.XLANGs.BTXEngine.PublishMessageException: Failed to publish (send) a message in the batch. This is usually because there is no one expecting to receive this message. The error was The published message could not be routed because no subscribers were found. with status -1061151998
Pop3 properties:
PipelineConfigurations:
I tried stopping the orchestration and the send port and test both locations.
Testing the email location I got the same error with an email with a .csv attachment.
Testing the file location the data didn't reach the database, but the csv was processed because I could see it in the information logs.
This leads me to the conclusion that the problem is related with the mime decoding and whatever my pipeline is outputing from the email body parts.
Also after researching for a while all solutions seem to point to the necessity of having a pipeline exclusively for email since I need to say which part of the multibody part to decode. I was hoping there was a solution that would allow me to reuse the pipeline I use for the file location.
As #Dijkgraaf mentioned:
It is not failing in the pipeline. It is failing due to there being no Orchestration or Send Port that is expecting the message the Receive Port has published to message box.
That means that the receive worked, that the message has passed the pipeline, and is published in the Messagebox, but there is no matching subscription.
Check for routing failures in the BizTalk management console to find out why. It may be that the message type is not waht you expected, or that one more published properties are not set correctly.
See the suspended message and check which body part is the CSV file. Your config says its it should be the 3rd message BodyPart = 2.
I am not new to BizTalk however this situation is somewhat new. I have below situation in an BizTalk Orchestration,
I get path of flat file from some other source.
I want to load this file in orchestration and disassemble it by executing pipeline.
I searched a lot but almost every one talks about feeding a XML document in pipeline inside orchestration.
I got below links too but I couldn't get the working solution so far,
Calling FlatFile pipeline inside orchestration
4 Different ways to process an XLANGMessage
When I implemented solution given at above links, I get error "No Disassemble stage components can recognize the data."
I also don't want to create dynamic receive locations because of performance constrains.
Below is my code so far,
Load file content in a stream
Create a CustomBTXMessage instance as suggested in link two.
Load stream as below
customBTXMessage = new CustomBTXMessage("MyMessageName",
Service.RootService.XlangStore.OwningContext);
customBTXMessage.AddPart(string.Empty, "Body");
customBTXMessage[0].LoadFrom(ms);
return customBTXMessage.GetMessageWrapperForUserCode();
I think this situation is not something new in BizTalk world. Any one who has done this must be able to help me quickly.
Here's what I would do...or at least try first.
Create a Receive Port and Receive Location for each Flat File type you get.
Get the list of files.
In the Orchestration, Move the file to the appropriate Receive Location.
Flat File Disassembler the file in Port Pipeline like normal.
Receive the File into the Orchestration with an Ordered Delivery Port bound to the Receive Port from Step 1.
Loop on Receiving the files, checking for BTS.LastInterchagneMessage.
When True, Exit that Loop and go back to step 3.
I have built a flatfile schema with the flatfile schema wizard.
The schema is valid and I could successfully validate my test instance against the schema.(So the XML file was created correctly).
But when I put my test flat file into a receive location that uses a flatfile disassembler pipeline, nothing happens after the receive location has picked up the message (the logical receive port is bounded to an orchestration)
In the BizTalk Admin Console I only see in the tracked message events from the pipeline that the message has been received. But not sent.
Maybe some of you already had a similar issue and could help me here.
Tracked message events in the pipeline
So. The issue was a wrong declared header schema. I have rebuild it and after that it was working fine.
I have recognized the issue by removing the header schema from the pipeline properties and trigger a new process. At this time the message was created correctly (but with the header line due to a missing header schema that would prevent that line).
Thanks to all who helped here!
I'am using the inbound-channel-adapter from Spring Integration to retrieve files over sftp from a remote server. Everything works fine.
But I have an additional requirement: after a file is received on the local side, that file needs to moved to a "send" directory on the remote server.
The "SFTP Outbound Gateway" has the appropriate method for that move action, but my problem is when to call it.
Situation: 10 files on remote server, 0 on local server
When I start my application it will receive all 10 files from the remote server and write them to my local file system. Perfect.
Situation: 1 file on remote server, 10 on local server
In this situation the remote file is received, but for every file on the local file system the receive method of the QueueChannel is also called.
Example log from one file: (file1.zip)
18:12:52.118 [task-scheduler-1] INFO o.s.i.file.FileReadingMessageSource - Created message: [[Payload File content=C:\Downloads\sftpTest\file1.zip][Headers=...]
18:12:52.119 [task-scheduler-1] DEBUG o.s.i.e.SourcePollingChannelAdapter - Poll resulted in Message: [Payload File content=C:\Downloads\sftpTest\file1.zip][Headers=...]
18:12:52.119 [task-scheduler-1] DEBUG o.s.integration.channel.QueueChannel - preSend on channel 'fromChannel', message: [Payload File content=C:\Downloads\sftpTest\file1.zip][...]
18:12:52.119 [task-scheduler-1] DEBUG o.s.integration.channel.QueueChannel - postSend (sent=true) on channel 'fromChannel', message: [Payload File content=C:\Downloads\sftpTest\file1.zip][Headers=...]
18:12:52.119 [main] DEBUG o.s.integration.channel.QueueChannel - postReceive on channel 'fromChannel', message: [Payload File content=C:\Downloads\sftpTest\file1.zip][Headers=......]
So even when the file it not physicaly retreived from the remote server, the channel.receive() method will still receive a message with that file as payload.
This confuses me, because I can't determine from the message if the file was already on the local file system or was just retrieved from the remote server.
I experimented using a custom org.springframework.messaging.support.ChannelInterceptorAdapter, FileFilter, ServiceActivator, but the problem still remains.
My application will process high volumes, so sending the received file to the required directory on the remote server is not an option. And also simply trying to move the file remote for every message that is locally received, is not an option since it will clutter the logfiles with exceptions of not being able to move the file. This way in case of an real error situation the problem will not be detected.
One solution might be a hook in the method copyFileToLocalDirectory of the org.springframework.integration.file.remote.synchronizer.AbstractInboundFileSynchronizer.
There is a check performed if the remote file should be deleted and that loop is only called for the files that were actually transferred from the remote server. My attempts to override this method and add my move behaviour did not succeed, since Spring has already instantiated the classes
that will handle this.
So what is the best way to achieve this? I know the problem will probably be located between my keyboard and my chair, but I've run out of options and any help is highly appreciated.
Thanks a lot,
Frank
You would probably be better off using MGET and an outbound gateway to retrieve the files instead of using the inbound adapter which, as you say, is two-stage - synchronize, and emit message(s) for file(s) in the local dir (unless you use a persistent file list filter, in which case you'll only see "new" files).
I want to pull something from the server (no delete), parse the file in the pipeline component, process the file, if everything goes successfully, I want the adapter delete the file.
i am thinking to enlist the parsing into the pipeline context, this way, I am picturing if the file cannot be parsed, the file will not get to the message box, therefore it will be deemed as a failed transaction, question, will the adapter participate in this transaction? in other words, my goal is to instruct the adapter to delete the file from the server ONLY when the pipeline processed successfully (transaction is commited), the file is left untouched on the server if the pipeline failed (transaction is rolled back, no message is commited to msg box)
Is this achievable? thanks in advance
I think a little experiment is in order. BizTalk, as part of it's nature, will not delete anything until it has been peristed to the message box. That being said, persitence might happen before PipeLine execution. So, the receive adapter receives the file, perists it to the message box and deletes the file. The message might subsequently fail in the pipeline. If this is the case, then the message is a bad format and it will have to be subsequently resubmitted by the sender. If you want to keep this message, you'll have to pick it up with Failed Message Routing. You can then write it to a directory and implement a resubmit pattern. Or, you can pick up the file via Failed Message Routing and put it back on the FTP server (this is sort of a compensation step).
On the otherhand, if the pipeline fails and the message isn't deleted fromt he server... you're fine.