Use a file deploy job, instead. There are several reasons why this approach won't work.
The usecase I have doesn't allow me to create a file deploy job. I do some processing on some files on the local server where the package is deployed and then do a copy of those files to another server.
Could you please detail on how a copy of files from one server to the other would work? Am I really limited with the options to continue using external command in a package?
use the NSH scripting to do the same.
I don't understand why you would be restricted from using a file deploy job, but would be allowed to deploy blpackages... but nonetheless....
External commands are executed in the native shell of that server (i.e. Windows CMD shell, or bsh for Linux, etc). The native shells for these servers don't support cp commands that allow you to specify other servers as sources or destinations (They are not NSH). That means you can't use NSH syntax there. In order to do what you are looking for, you either need to use commands that the native shell recognizes (mounting a network drive to the other host and then copying to that share) or install NSH on the host you are trying to execute the external command on. Then, you would need to make sure it is setup properly (i.e. configure it to use an NSH proxy, if applicable).
Thanks for the comments Adam.
nsh -c "cp //@/C/temp/test.txt //target_server/tmp/test.txt"
This was my original command in the external command but as it errored out I tried with plain cp. I understand what you are trying to say about the native shell and the NSH syntax. It was just a try to see on how plain cp behaves.
Do you think the above command should work if the nsh proxy is set? I was just curious about the SSO. How would the token from app server pass to the package deployed server which then talks to target server?
Create NSHScript to authenticate and copy the files from one server to other and place it on windows box. Parameterize password, target server and location,so that you can pass all these information in external cmd within BLPackage.
Then run external command to execute NSHScript.
In this case it really can't, if you are using an NSH proxy. Which is why I said it wouldn't work. You can't pass your credentials from the appserver to the target. Can you not execute a type3 NSH script job to do this for you? The file deploy job would be your correct route, though. Why do you HAVE to use a BLPackage? This doesn't make sense to me.
I really would advise against doing that, Siddu. That information will be transmitted, logged, and stored in clear text. Use a file deploy job or a type 3 NSH script job.
type3 NSH script job and file deploy jobs can't really run on components. The target has to be always servers. The other consideration is that I can't parameterize paths in file deploy jobs and NSH script jobs. I need to evaluate the paths and other parameters at runtime which can be read from property dictionary. I have multiple environments with in the same server and the way we chose for targets is components with PSI (Prop Set Instance). This way I have runtime evaluation of parameters.
If parameterization and component targets were allowed, file deploy job would have been apt for my usecase. The only reason to choose blpackages was the limitation with file deploy job.
Any more ideas?
Pretty much sure this usecase would have been needed by many. I am guessing there should be some kind of mechanism to pass the SSO token from appserver to another server. I am not really sure how to achieve it with my limited knowledge of BSA.
1 of 1 people found this helpful
so, why can't you create a properties file with the blpackage that contains the source and destination and then execute a type 3 NSH script job that reads this properities file and executes the copy?
Thats the workaround implemented. We create a temporary NSH script from package and then execute and delete it. We have limited the parallel execution to 1 and plan to put around locks using some other orchestration wrapper. I thought its a hacky solution and intended to implement with a neat approach.
this has been discussed recently here before - a couple notes:
- when you use a file deploy job or a nsh copy the files are going to go 'through' the appserver because the copy was initiated there, and not directly on the source system. meaning adding another leg of communication and likely slowing down the copy transaction, especially if there is a wan between the source and appserver.
- the only way to do a direct source to target copy is to initiate the copy on the source, for example a nexec of a copy command or via the 'external command' in the blpackage
- to use nsh copy from the source you must have nsh installed on the source server
- you will lose your credentials so we will fall back to os user name mapping, meaning the source will connect to the target and pass the username on the source that's initiating the copy command, eg 'Administrator' or something.
- this means that there must be a mapping entry in the users or users.local on the target to map that connection to a local user that can write to the target location, and the target server needs to be able to accept direct connections from the source (exports file)
- if you configured the source server to use a nsh proxy you'd be copying the files 'through' the appserver again so that's not a great idea
so, to use nsh to do the direct copy you would need to:
- install nsh on the source
- configure the exports/users/users.local on the target to take connections directly from the source and map the incomming connection from the source to a local account on the target
- use a nsh job that nexec's the cp command or runs the cp in the 'external command' of the blpackage.
Thanks for the detailed explanation. We will try this out. We are not worried about the app server being the man in the middle for file copies as we dont have huge MB's/GB's of file to copy. I was more interested on how to pass the credentials. Your explanation sums up everything including the copy optimizations and credentials aspects.