I want your thoughts to implement below solution.
Need to read files from source system using https. Have to transfer it to target using ftp mechanism. Frequency of files is every 3 hours, around 100 files. Avg file size is 30KB.
Please give your algorithm approach to design solution to above interface.
Also, suggest, is it good to keep the files in wM local FS, so that if there is any issue with target system, webMethods can give a try to push it again using ftp. Using wM8.0 verison.
Thanks for your time for reading this thread.
you should consider an upgrade of your wM Version to a current 9.x version.
Unfortunately there are no direct upgrade pathes from 8.0 to 9.x.
This benefits in having a SFTP option since 9.5 SP1, before that IS only supports FTP and FTPS.
You might want to take a glance at ActiveTransfer and see if this will be helpful in your case.
I am not experienced with getting files via HTTPS as we have only posted using HTTPS. However, if SFTP is needed at your version for transferring to the target system, you may be able to use the OpenSSH package. We are using that at 8.2.
Regarding reprocessing files if there is an issue with the test system, that sounds like a good idea, especially if the files you are retrieving via the HTTPS method are transient and not easily recoverable. You may want to create archive and error directories on your wM IS and write the file to the archive when it is successful and the error when it is not. Then you can resend from the error directory.
Thanks for your inputs.
@Holger: If it is wM9.7, kindly suggest required steps to implement the interface.
in this case have a look ath the WebServices Developers Guide as well as the IntegrationServer Build-In-Services Guide and IntegrationServer Administration Guide.
Thanks Holger, got the idea to proceed further.
As part of this, created a service which in-turn using pub.client:http service which is invoking source system to get the data. Created keystore, truststore files, configured the same in IS admin page. Created a https port alloted 8686 as the port number. When creating the webService provider for the just created service got below Warning:
Selected transport protocol doesn’t match that of the primary port on the Integration Server. Would you like to continue. I opted yes, it created the webService.
When I am testing the same wsdl url in soap, it it saying – There was something wrong with the WSDL you are tying to import … nothing was created in soap.
Please suggest steps from here on.
which http type is your primary IS port (HTTP or HTTPS)?
Use this protocol to create the WSDL.
You change the WSD Provider node to HTTPS later on by switching the WS Endpoint Alias.
Unfortunately, webMethods-generated WSDLs are not always correct.
Can you export the WSDL and provide it to use for verification?
It can be found under http://:/ws/?WSDL
Copy the Service Name (or the WSDL-URL directly) from the Designer.
Is there a more detailed error message from SoapUI when trying to import the WSDL?
Please see the below approach.
1.Configure keystore, truststore in your IS.
Write a service like below:
2 .In the serivce, use setKeyAndChain BIS passing keystore system details.
3.write a service which has pub.client:http service which calls to source system which sends streams as response.
4. use clearKeyAndChain service.
Based on the response from the source, implement your business logic.
If you need more clarity, see documentation.
If you are using Trading Networks, data can be routed thru TN if re submission is the concern in case target is down. Saving them on Local File Share may not be great idea. you can run into disk space issues later.
We have made reusable flows for common file transfer scenarios such as ftp site to ftp site, sftp site to ftp site, ftp site to sftp site, etc.
We have created a document type for the corresponding parm: ftpParms, sftpParms, httpsParms.
Building the common flows using this document types for inputs. Also, include as an output a success flag and a message. I use the message to indicate to action performed in the flow or the exception. Make sure to clear pipeline in the common flows except the success flag and the message or things can get hairy!
We started using common file transfer flows a few years ago. What’s nice is that they get called hundreds of thousand times per month so we know we have the bugs worked out!
Also, try to wrap any external calls with a retry statement. A few retries with a 30 second delay will prevent those nasty support issues due to network hiccups.
wrightbp.43724, is that services shareable which you developed. If yes, it will be really helpful to many.
Unfortunately, there is too much sharing across other custom packages to share.