I've downlaoded the nsoftware sftp adapter for Biztalk.
I created a few send & receive ports within Biztalk admin just to see if it works, and it does.
I now need to build an orchestration with an sftp send port and sftp receive port.
I've added a reference to the adapter dll and included it in the project, but I'm not sure how to wire it up to my 2 ports in the .odx file.
Can anyone shove me in the right direction?
The only reason you'd have a project-level reference to the adapter DLL is if you need to use the property schemas for the nsoftware adapter; otherwise, the way you'd use it is the same way you'd use any other BizTalk adapter:
Declare your logical ports in your orchestration. Make sure you mark them as "Specify Later" (or direct/dynamic, if you're doing more advanced scenarios).
Build your orchestration as usual
Deploy
Go to the BizTalk administration console and create receive locations/send ports as necessary specifying the nsoftware SFTP adapter. You'll be able to enter all the adapter configuration settings there.
If you could share any more details about what you're trying to do, maybe I could offer more specific advice.
Related
I am using BizTalk 2020 and starting in BizTalk 2016, it provides a native SFTP adapter which is a wrapper around WinSCP. I'm trying to move out of the BizTalk nSoftware SFTP adapter and utilized BizTalk native SFTP adapter.
I tested this out and it works if I hard-code the host name, user name and password. But I would like to know if it is possible to use a context variable like one highlighted below so that the sftp destination can be changed based on each's message context? if so how?
so far when I ran the test it fails to associates the variable SSHHost with the value found in the context of the message:
Currently this is how our Send Port which uses the 3rd party adapter and it works well.
I have a very simple BizTalk application that is polling the records from a SQL server and does some transformation then save it to the Oracle DB. I used BizTalk 2010, SQL server 2012, Oracle 11g each is hosted on their own separate server. BizTalk was setup properly and has been working fine.
I have attached the orchestration diagram for clarity. Nothing fancy, I have set up the sending and receiving port successfully (can connect to all the database, and I used typedpolling for inbound and insert operation for the outbound. The project can be compiled and deployed successfully.
I have imported the bindings to BizTalk Admin Console and can see both bindings on the receive port and send port. The following image shows the bindings for send port is there.
However, when I tried to configure the Orchestration, I can only see the receive Ports in the selection but the send ports information is not available for me to pick.
From my limited exposure to BizTalk in the past, I can select the send port once I have imported the bindings to the console. I wonder what I have done incorrectly this time?
Usually a table operation such as an insert will be a request (the insert) and the response which shows it has succeeded (with an array/list of ID's of the new records). If you look the port that was created from the bindings you will see both a Send pipeline and a Receive Pipeline. Just make the port in the Orchestration a Request/Response, and consume the response (even if you don't do anything with it). Then you can bind the logical port the the actual port one as the logical port will then match the port.
I am inheriting a project which I am migrating from 2006 to 2010.
From what I understand, when I deploy a BizTalk solution from Visual Studio, the required ports should have stubs created automatically in the application.
Currently no ports are being created when I deploy. Is there a configuration option I'm missing for this, or am I incorrect in my understanding and have to send up all the ports manually?
Send/Receive Ports will only be created automagically if you have an Orchestration/s that has a Send or Receive Port configured with its Binding as 'Specify Now' - this approach bakes the port configuration into the Orchestration and is then created when you deploy:
You will also see really funky Receive Port names following the deployment:
and Receive Location names:
This is the wrong approach IMHO - Send and Receive Ports should be created, configured and bound manually via the BizTalk Administration Console once you have deployed your solution. This way, you separate your service (orchestrations etc.) from your configuration bindings, which may change with each environment. Furthermore, you don't have funky port names in production that will need to be deleted :-)
I would recommend scripting the deployment once you have sufficient knowledge of BizTalk - this will also include importing configuration bindings once you have deployed your BizTalk assemblies (Orchestrations, Schemas, Pipelines etc.)
I am using a BizTalk orchestration to kick off an SSIS package. This package is essentially doing transformation on behalf of BizTalk on a very large volume of data. I have run into a problem as to the best way of specify in the drop location for SSIS use after the transformation. If this were a 'normal' BizTalk orchestration it would be easy to set up a send port. I would like to make a fake send port in BizTalk so that the admin could configure the send location from BizTalk and then have BizTalk pass that value into SSIS. However, if you configure a send port without actually attaching a connector to it, then it will not show up as an available binding in BizTalk admin.
Is there a way to get around this and force the admin to bind it before starting the orchestration? Any other ideas to allow for an easy configuration of this round-about process?
What I ended up doing was creating a decision shape that was true on one side so it never would go down the false branch. In essence I tricked BizTalk, so I could attach a connector to the send port that I am interested. Earlier in the orchestration I retrieved the value of the file location for the 'config' send port, so I can could send it to SSIS.
For a distributed production client-server WCF application (self-hosted as a Windows Service with NetTcpBinding), I am adding logic to add expception to Windows Firewall during the installation via netsh command.
I have noticed that the remote communication seems to work fine whether the firewall exception is for the program (the executable) or port. In our case, the port will very rarely be something other than the default and if it is then user can manually alter config files and firewall accordingly.
My question is, whether it is better to add the exception for program OR port OR both. Are there any security considerations making one approach more desirable than the other? Virtually all of the examples for WCF show port exceptions.
Any insight would be appreciated, thanks.
Here is my summary of how I think they function:
Application exception --> grants the specified application to open any ports
Port exception --> grants any application to open the specified port
As such, which one is better suited depends on the situation. Generally, the application exception would be preferred. At the time an application attempts to open a port, the Windows Firewall (if enabled) essentially would do a check to determine if that application or the port itself has been granted an exception.
MSDN states: "[Application exception] is more secure than opening a port, because the firewall is only open while the program is waiting to receive the connection."
More detailed MSDN summary and technical articles: http://technet.microsoft.com/en-us/network/bb545423.aspx
Ultimately, the system admin for the deployed software should be aware of and/or be the one who makes the changes to the firewall. What we plan on doing is having a step in the installer where the customer can opt-out of the firewall exception but explaining that remote clients will not be able to communicate without it. And of course the manual documentation will also outline the required ports for scenarios if other software or hardware firewalls are in place and need to be manually configured.