I have a legacy system which can create files visible in WebDav as an output. I'd like to trigger a BizTalk orchestration receive port when a file matching a filter appears - so a lot like the standard File adapter, but for WebDav.
I found the BizTalk Scheduled Task Adapter, which can pull in a file by HTTP, but it looks abandoned, poorly documented, and out of date.
So, how is it done? Can I use the standard HTTP adapter perhaps?
If you're able access the WebDAV via a UNC path from the BizTalk server the File Adapter should do the trick.
Have you tried to assign a drive letter to the WebDav folder?
http://en.wikipedia.org/wiki/WebDAV
We've had to go with a workaround on this where we made a completely unrelated separate process to make a copy of the file from the legacy system appear in a Samba share, which we in turn attach to with an ordinary FILE adapter.
Related
I am beginner to WebDAV/HTTP protocol. I want to transfer files across network using WebDAV. The source received camera image raw data files has to be placed in a webDAV server (a folder). These files are then copied by a remote client via webDAV. my questions below
Is it necessary to use webDAV/HTTP GET/POST/PUT method calls on the server machine to copy images
or just a normal Linux/QNX command shall work?
If we do not need to go via WebDAV just to copy files then how can we attach properties to these
files like file name and size? are these automatically supplied to remote client by webDAV using
some OS file system calls?
Thank you in advance for your answers
I have a file on my desktop and I need to get it onto another server, but I have no means of getting it there, i.e. email/usb or any way like that.
The server is on the same network as me.
I have heard of a way that the file can be copied via the command line.
Would anyone have any information on this and if so could you please help me?
Not sure whether you have command line access to that server or not? If yes, are you accessing it via telnet or via ssh?
If ssh, you should be able to transfer the file via SCP (secure copy), since it uses the same ssh connection you use to get your cli. If you want to transfer your file from a Windows environment, you may want to look at WinSCP, else do a man scp on your Linux or Unix server and, assuming you have it, you'll get the hang of it... it's not complicated.
If ssh is not an option, then you depend on the server having some service available for you to transfer the file, most obvious one being FTP.
Does that help?
I have a configurable service (CDServer). When I try to deploy my WMB flow that uses a CDInput Node, which is using the configurable service I got the following error:
BIP7962E: File path '\\192.168.45.91\myfolder' specified for the property 'brokerPathToInputDir' in the CDServer configurable service is not valid.
The file path is accesible from my Windows Explorer. The folder "myfolder" is shared on the remote computer.
I don't know where could be the error. I've tried chanching the file path to a different format (192.168.45.91\myfolder), but still doesn´t work.
I'm using:
WMB 8.0.0.1
MQ 7
Sterling Connect Direct 4.6
Any help on this issue is very appreciated.
I'm up against the same problem. While I continue to hope for a solution that works like yours, my manager told me yesterday he had wrestled with the problem a year ago, and the only solution he found was to put an SFTP server in the middle. For his message flow, he used Attachmate Reflection.
The FileInput node has hooks for remote access. On the FTP tab, click Remote Transfer and fill in the Attachmate server and port, and other settings. Attachmate in turn is configured with a virtual folder, which accesses the actual remote server.
It seems like more machinery than is necessary, but you can't argue with the fact that it works and has been in production for over a year.
We are using Tridion 2011 SP1. Some of the pages/components are getting failed while publishing with below mentioned error.
Phase: Deployer Prepare Phase failed, Unable to unzip,
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process),
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process), Unable to unzip,
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process),
D:\Inetpub\TridionPublisherFS4SP\incoming\tcm_0-286137-66560.Content.zip (The process
cannot access the file because it is being used by another process)
Components/Pages are failing under stage Preparing Deployment, how should we fix it?
Do you have multiple Deployers using the same incoming location?
It looks like you’re running the Deployer as a WebApp – is the Deployer service also running on the system?
If you search for all files named “cd_deployer_conf.xml”, do they have the same incoming folder (D:\Inetpub\TridionPublisherFS4SP\incoming) defined?
Otherwise, you might use ProcMon to watch the folder and see what else is accessing the file.
If you still have this issue, you may try
1. deleting all files under incoming,
2. making sure there is no encryption enabled for the incoming folder (Some companies apply encrypt script immediately to the files that are added to the drive) or
3. making sure your antivirus is not screening that folder (As Nuno mentioned).
Do a restart of the deployer app and verify in the logs?
Is there any way to recover the physical send & receive ports once deleted without exporting the bindings?
Even if you export the bindings the ports will not exist and so will not be exported. I think Bilal is correct - this data resides in the management database, so you would need to restore from a backup.
Your best option is always have a binding file configuration for your application. Once your BizTalk applications are configured with correct send, receive ports, orchestration host etc make sure you back up your binding configuration using "Export Binding" option in BizTalk admin console.
In fact, in bigger projects binding files will be normally owned by deployment teams for various environments and you never create ports using admin console in real environments.
It will be bit overkill to restore your BizTalk databases, just get your ports back. I would rather create them manually again, even if the numbers are hight. Restoring databases requires special attention, if you do it wrong you will end up reconfiguring the whole environment which will be time consuming.
I agree with Saravana.
My 5c: you can import existed binding files and that will not remove ports that are not in the binding files. The import process works in "addition" mode.