go to post Duncan Priest · Mar 22, 2019 After much investigation deep into the bowels of Ensemble's SOAP handling with no solutions found, I made the decision to build a new namespace with fresh databases to see what would happen, and the problem didn't appear. So, cause unknown, but seems likely to have been something screwy about the databases (which it turned out had a questionable origin, rather than being freshly created). The infamous question "Have you tried turning it off and then on again?" comes to mind although in this case the solution was a little more drastic.
go to post Duncan Priest · Jan 15, 2019 Well, months later I stumbled across the answer myself after needing to recreate the web services from modified WSDL. It seems that the problem was the options I selected when originally generating the classes from the WSDL using the SOAP Wizard. I had been using "Class Type: Serial" to avoid cluttering the database with lots of unnecessary tables, but changing this to Persistent (+using indexed one-many relationships) produced classes that no longer give the problem - I now get SOAP requests with empty elements included in the correct form . (At least I assume this was the change that fixed the issue, I also selected "Use unwrapped message format for document style web methods", but I imagine it was the class type that made the difference.)
go to post Duncan Priest · Aug 2, 2017 Actually I just noticed the "Semaphore Specification" setting on the EnsLib.File.InboundAdapter which looks to possibly be relevant to your needs. In the help text for this is the following:"The semaphore sepcification (sic) can be a wildcard filename pairing of target=semaphore filename e.g. ABC*.TXT=ABC*.SEM which means do not process any files found that match ABC*.TXT unless a corresponding ABC*.SEM exists for each one."May not be relevant but thought I'd pass it on.
go to post Duncan Priest · Aug 1, 2017 Hi SalmaMy first thought is that you could write a custom service class to extend EnsLib.File.PassthroughService and within it override the OnProcessInput method. In here you would perform your IO functionality to read the second file into a stream, set the streams for both files to properties of a custom message that you define (extending Ens.Request), before passing the custom message on to the target process or operation. You would also need to perform matching processing in a custom operation to write both files to the target folder.But all of this really assumes that you want to do something useful with the file streams along the way. If all you want to do is copy them both as soon as they arrive in an input folder, why not just set up 2 x pass through services, each detecting a different file extension and both targeting the same operation. On re-reading your question, it looks like timing for the two files may be the issue though, in which case I'd stick with the custom service/request/operation classes.RegardsDuncan
