Announcement Announcement Module
Collapse
No announcement yet.
Need a non null response from SFTP outbound adapter Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Need a non null response from SFTP outbound adapter

    Hi everyone,

    I'm trying to get feedback of any kind from a SFTP outbound adapter without any luck.
    I understand that this is by design, however, I want to be able to tell whether the adapter was successful sending the files to its destination and propagate this message to the gateway's calling call.
    Is that possible?
    If not, can you recommend a new approach to get a response for a SFTP PUT operation?

    Thanks.

  • #2
    On technique is to make the final channel (before the outbound adapter) a <publish-subscribe-channel/> subscribe the adapter (order="1") and a <transformer/> (order="2").

    The transformer will only get the message if the sftp put was successful; you can transform the message to a result, and send it wherever you like.

    Comment


    • #3
      following your advice, I'm having a bit of a problem with the message to send:
      The SFTP outbound adapter requires a java.io.File type of message, while the transformer requires another object.
      Is it possible to send different type of messages to different subscribers? or alternatively, pass the outbound adapter (using expression perhaps) just the relevant portion of payload which contain the file to be put?

      Comment


      • #4
        I am not sure I understand what you mean by

        while the transformer requires another object
        A transformer can transform anything to anything - you can even ignore the actual inbound payload if you want. Try

        Code:
        <transformer input-channel="in" output-channel="out" expression="ok"/>
        or


        Code:
        <transformer input-channel="in" output-channel="out" expression="payload.absolutePath + ' processed ok'"/>

        Comment


        • #5
          Let me try to explain by code:
          Code:
          <!-- Submit the file to supplier -->
          <integration:publish-subscribe-channel id="notifysupplier"/>
          
          <int-sftp:outbound-channel-adapter id="supplierSecuredFileTransfer"
          								   session-factory="sftpSessionFactory"
          								   channel="notifysupplier"
          								   remote-filename-generator-expression="cancellations.TKT"
          								   remote-directory="/var/tmp"
          								   order="1" />
          								   
          <!-- Delete the notification records marked as successful -->
          <integration:service-activator id="deleteNotificationRecords" 
          							   input-channel="notifysupplier" 
          							   ref="supplierDatabaseService" 
          							   method="removeNotificationEntries"
          							   order="2"/>
          Messages sent to the channel "notifySupplier" must be of the types java.io.File, String or byte[] for the consumption of the SFTP outbound adapter (supplierSecuredFileTransfer), while I need a different Message type to be passed to the service-activator (deleteNotificationRecords). Is that clearer?

          Comment


          • #6
            You just need to add a transformer before deleteNotificationRecords to create a payload that will match the method signature for removeNotificationEntries?

            Code:
            <int:transformer input-channel="notifysupplier" output-channel="finalNotify" 
                order="2"
                expression="something to change the payload to match the signature"/>
            
            <integration:service-activator id="deleteNotificationRecords" 
            							   input-channel="finalNotify" 
            							   ref="supplierDatabaseService" 
            							   method="removeNotificationEntries"/>

            Comment


            • #7
              The order here matters. outbound adapter should run first, therefore "notifysupplier" should get a File payload.
              The service-activator (deleteNotificationRecords) which runs afterwards (order="2") requires a different object as payload (which the File is a part of it).

              What would be great if I can apply a similar logic like the one you suggested and place the transformer first passing the File to the adapter, while the service-activator gets the larger payload message.

              Comment


              • #8
                Well, then reverse the logic and put the transformer before the adapter instead.

                Code:
                <integration:publish-subscribe-channel id="notifysupplier"/>
                
                <int:transformer input-channel="notifysupplier" output-channel="toFTP" 
                    order="1"
                    expression="payload.file"/> <!-- assumes your big object has a method getFile() -->
                
                <int-sftp:outbound-channel-adapter id="supplierSecuredFileTransfer"
                						   session-factory="sftpSessionFactory"
                						   channel="toFTP"
                						   remote-filename-generator-expression="cancellations.TKT"
                						   remote-directory="/var/tmp"/>
                								   
                <!-- Delete the notification records marked as successful -->
                <integration:service-activator id="deleteNotificationRecords" 
                							   input-channel="notifysupplier" 
                							   ref="supplierDatabaseService" 
                							   method="removeNotificationEntries"
                                                                           order="2"/>
                The big object will FIRST (order=1) be sent to the transformer, transformed to a File and sent to FTP; if successful, the big object will then be sent to the <service-activator/> (order=2).
                Last edited by Gary Russell; Apr 11th, 2012, 10:53 AM.

                Comment


                • #9
                  Is the output-channel of the transformer correct? Shouldn't it point to the adapter (supplierSecuredFileTransfer)?

                  Not sure how you should wire the adapter. On one hand it needs to adapt the notifysupplier channel (input-channel="notifysupplier"), and on the other hand it should be wired to the transformer to get the 'reduced' payload (input-channel=transformer-id).

                  Is that correct?

                  Comment


                  • #10
                    Yes, sorry - I just fixed it, the transformer output-channel is the adapter's input channel.

                    Comment


                    • #11
                      It seems logically right, I will give it a go tomorrow and update.
                      Thanks for all your efforts, I appreciate it.

                      Comment


                      • #12
                        Seem to be working with a single exception: when the wepapp is stopped I get the following error:
                        Code:
                        20120412-113631.414 ERROR [org.apache.catalina.loader.WebappClassLoader] The web application [] appears to have started a thread named [Connect thread ftptest.yahoo.com session] but has failed to stop it. This is very likely to create a memory leak
                        Looks like the STFP thread opened with the outbound adapter did not end properly.
                        Last edited by jackrabbit; Apr 15th, 2012, 01:04 AM.

                        Comment


                        • #13
                          Gary, could you please relate to this issue? It's rather important to me.

                          Thanks

                          Comment


                          • #14
                            This thread '[Connect thread ftptest.yahoo.com session]' is created by the jsch library and it's not made a daemon by default. We expose a property on the DefaultSftpSessionFactory that instructs jsch to create daemon threads, which will avoid the message from Tomcat.

                            Code:
                            <bean id="sftpSessionFactory" class="org.springframework.integration.sftp.session.DefaultSftpSessionFactory">
                            	...
                            	<property name="enableDaemonThread" value="true"/>
                            </bean>
                            We should probably point this out in the reference manual; please feel free to open a 'Documentation' JIRA; thanks.

                            That said, although scary, the message is benign (in this case), it is just saying that the sftp connect thread didn't stop on its own when you shut down Tomcat, not a big deal really.

                            Comment


                            • #15
                              JIRA ticket opened

                              Comment

                              Working...
                              X