2015-09-03 4 views
1

Я использую WSO2ESB 4.8.1. На данный момент я пытаюсь создать довольно простой сервис, который будет читать файлы из одной папки и записывать их в другую. Все папки находятся на одном физическом разделе.Сетевой адаптер WSO2ESB - transport.vfs

Я следовал инструкциям на VFS+Transport и на Sample File Processing

это моя простая конфигурация обработки файлов прокси:

<?xml version="1.0" encoding="UTF-8"?> 
<proxy xmlns="http://ws.apache.org/ns/synapse" name="FileProcessorProxy" transports="vfs" startOnLoad="true" trace="disable"> 
     <target> 
      <inSequence> 
       <log level="full"/> 
       <property xmlns:ns2="http://org.apache.synapse/xsd" name="transport.vfs.ReplyFileName" expression="fn:concat(fn:substring-after(get-property('MessageID'), 'urn:uuid:'), '.txt')" scope="transport" type="STRING"/> 
       <property name="OUT_ONLY" value="true" scope="default" type="STRING"/> 
       <send> 
        <endpoint> 
         <address uri="vfs:file:///opt/wso2/wso2data/esboverviewtest/out"/> 
        </endpoint> 
       </send> 
      </inSequence> 
     </target> 
     <parameter name="transport.vfs.ActionAfterProcess">MOVE</parameter> 
     <parameter name="transport.PollInterval">5</parameter> 
     <parameter name="transport.vfs.MoveAfterProcess">file:///opt/wso2/wso2data/esboverviewtest/original</parameter> 
     <parameter name="transport.vfs.FileURI">file:///opt/wso2/wso2data/esboverviewtest/in</parameter> 
     <parameter name="transport.vfs.MoveAfterFailure">file:///opt/wso2/wso2data/esboverviewtest/failure</parameter> 
     <parameter name="transport.vfs.FileNamePattern">.*.txt</parameter> 
     <parameter name="transport.vfs.ContentType">text/plain</parameter> 
     <parameter name="transport.vfs.ActionAfterFailure">MOVE</parameter> 
     <parameter name="transport.vfs.MoveTimestampFormat">yyyy-MM-dd'T'HH:mm:ss.SSSZ_</parameter> 
     <parameter name="transport.vfs.FailedRecordsFileDestination">file:///opt/wso2/wso2data/esboverviewtest</parameter> 
     <parameter name="transport.vfs.FailedRecordsFileName">transferFails.log</parameter> 
     <parameter name="transport.vfs.MoveFailedRecordTimestampFormat">yyyy-MM-dd'T'HH:mm:ss.SSSZ_</parameter> 
</proxy> 

В целом, это работает. Когда я помещаю файл в папку «in», он перемещается в «выходы» и «оригинальные» каталоги.

Проблема, которую я начал, когда я начал проверять, что произойдет, если «вне» или «оригинальные» каталоги недоступны ... например, при перемещении нового входящего файла произошла ошибка.

Оказывается, что, несмотря документации на веб-сайте WSO2 таких параметров, как:

transport.vfs.MoveAfterFailure 
transport.vfs.ActionAfterFailure 
transport.vfs.FailedRecordsFileDestination 
transport.vfs.FailedRecordsFileName 
transport.vfs.MoveFailedRecordTimestampFormat 

просто абсолютно IGNORED ... в случае любого сбоя при передаче файла не «из» директории файл не помещал в папка «сбой».

это журналы:

TID: [0] [ESB] [2015-09-03 21:43:41,120] INFO {org.apache.synapse.mediators.builtin.LogMediator} - To: , WSAction: urn:mediate, SOAPAction: urn:mediate, MessageID: urn:uuid:86C197EE849A6CA9071441298621105, Direction: request, Envelope: <?xml version="1.0" encoding="utf-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><text xmlns="http://ws.apache.org/commons/ns/payload">test message 1 
</text></soapenv:Body></soapenv:Envelope> {org.apache.synapse.mediators.builtin.LogMediator} 
TID: [0] [ESB] [2015-09-03 21:43:41,128] INFO {org.apache.synapse.core.axis2.TimeoutHandler} - This engine will expire all callbacks after : 120 seconds, irrespective of the timeout action, after the specified or optional timeout {org.apache.synapse.core.axis2.TimeoutHandler} 
TID: [0] [ESB] [2015-09-03 21:43:41,134] ERROR {org.apache.synapse.transport.vfs.VFSUtils} - Cannot get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out before processing {org.apache.synapse.transport.vfs.VFSUtils} 
TID: [0] [ESB] [2015-09-03 21:43:41,135] WARN {org.apache.synapse.transport.vfs.VFSTransportSender} - Couldn't get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out, retry : 1 scheduled after : 30000 {org.apache.synapse.transport.vfs.VFSTransportSender} 
TID: [0] [ESB] [2015-09-03 21:44:11,136] ERROR {org.apache.synapse.transport.vfs.VFSUtils} - Cannot get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out before processing {org.apache.synapse.transport.vfs.VFSUtils} 
TID: [0] [ESB] [2015-09-03 21:44:11,136] WARN {org.apache.synapse.transport.vfs.VFSTransportSender} - Couldn't get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out, retry : 2 scheduled after : 30000 {org.apache.synapse.transport.vfs.VFSTransportSender} 
TID: [0] [ESB] [2015-09-03 21:44:41,137] ERROR {org.apache.synapse.transport.vfs.VFSUtils} - Cannot get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out before processing {org.apache.synapse.transport.vfs.VFSUtils} 
TID: [0] [ESB] [2015-09-03 21:44:41,137] WARN {org.apache.synapse.transport.vfs.VFSTransportSender} - Couldn't get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out, retry : 3 scheduled after : 30000 {org.apache.synapse.transport.vfs.VFSTransportSender} 
TID: [0] [ESB] [2015-09-03 21:45:11,138] ERROR {org.apache.synapse.transport.vfs.VFSUtils} - Cannot get the lock for the file : file:///XXXopt/wso2/wso2data/esboverviewtest/out before processing {org.apache.synapse.transport.vfs.VFSUtils} 
TID: [0] [ESB] [2015-09-03 21:45:11,139] ERROR {org.apache.synapse.transport.vfs.VFSTransportSender} - Couldn't send the message to file : file:///XXXopt/wso2/wso2data/esboverviewtest/out, unable to acquire the lock even after 4 retries {org.apache.synapse.transport.vfs.VFSTransportSender} 
TID: [0] [ESB] [2015-09-03 21:45:11,140] INFO {org.apache.axis2.engine.AxisEngine} - [MessageContext: logID=9ffc75049fa389747d1fe3eac64c356ce001a7d103ba20fd] Couldn't send the message to file : file:///XXXopt/wso2/wso2data/esboverviewtest/out, unable to acquire the lock even after 4 retries {org.apache.axis2.engine.AxisEngine} 

Файл перемещен в «оригинал» (что нормально) и но после 4 попыток файл был просто отбрасывается, папка «неудача» была оставлена ​​пустой ...

Более этого, свойства transport.vfs.FailedRecordsFileDestination и transport.vfs.FailedRecordsFileName также были проигнорированы, и не какой-либо файл был создан, который должен содержать перечень проблемных передач ...

вопрос заключается в том, что, как настроить надежная передача файлов с помощью WSO2ESB, чтобы можно было отслеживать, какие файлы были успешно перенесены и какие файлы должны быть переработаны.

ответ

1

В случае отказа ваш входной файл будет перемещен в транспорт .vfs.MoveAfterFailure. Но здесь «отказ» означает случай, когда ESB не может прочитать файл или создать его содержимое.

Например, вы настраиваете transport.vfs.ContentType как application/xml, а содержимое вашего файла - плоский текст: он будет перемещен в файл transport.vfs.MoveAfterFailure.

Как только содержимое вашего входного файла было отправлено в ваш inSequence, независимо вопрос вашего посредничества может быть, файл будет перемещен в transport.vfs.MoveAfterProcess

transport.vfs.FailedRecordsFileName является имя файла для сохранения списка файлов сбоев. Default is repository/conf/vfs-move-failed-records.properties

Существует второй шанс с транспортом.vfs.MoveAfterFailedMove: новый пункт назначения для перемещения файла с ошибкой.

Если вы хотите выбрать внутри своей медиации (в качестве примера ошибки) другой каталог, в который должен быть перемещен входной файл, вам необходимо расширить org.apache.synapse.transport.vfs.VFSTransportListener, поместить свой. jar в репозиторий/компоненты/lib и настройте свой конкретный класс на ось 2.xml

+0

Благодарим вас за подробное объяснение. Я удивлен, что документация wso2esb не упоминает этот тип деталей. Но это был файл org.apache.synapse.transport.vfs.VFSTransportSender, который отбросил это сообщение, а не org.apache.synapse.transport.vfs.VFSTransportListener. Может быть, я должен заглянуть в VFSTransportSender вместо VFSTransportListener? или их обоих? – Nariman

+0

transport.vfs.MoveAfterXXX управляется VFSTransportListener, поэтому, если есть проблема с «оригинальным» каталогом, используемым для MoveAfterProcess, это VFSTransportListener. –

+0

Если есть проблема с каталогом «out», который используется в вашей отправке, VFSTransportSender выдаст ошибку, и ваша ошибка будет выполнена, ваше оповещение закончится, и VFSTransportListener решит переместить ваш файл в MoveAfterProcess ... Вы можете сохранить свой сообщение в свойстве и решить, в вашей ошибкеSequence, отправить его в другой каталог (в локальную файловую систему). Но это не сработает, если вы используете потоковое видео для огромного сообщения. –