File Transfer Paths lost in an ALIAS job - retains original job's paths

[shravani_vedantham_6826]

Hi

I am looking for a solution for an issue we are currently facing in Production after migrating from AM V8.10 to A.E 12.0.2

Here is the background : We support a wide range of File Transfers from one server to many servers. In order to save up memory in DB and also to avoid multiple jobs where Source is always the same. We have come up with a solution to create one Base Job and use that job as an ALIAS in all other JOBP's where needed. The job is added to the JOBP/Flow and only the task properties is changed as per the destination.(like, the login, file paths etc.,)

Now the issue is , after creating a new flow with the ALIAS job in it, save it and close. When the job actually is scheduled to run, the FTP tab loses its information and retains the Base job's values and fails.

Again, this doesn't happen all the time, but happens often. The times when it happened/this was noticed is

1. When it is transported from another client/Environment
2. Copy a JOBP with ALIAS jobs in it
3. this even happens when there are two ALIAS jobs in a JOBP and only 1 is modified , the other loses

This really is creating an issue and re-work as we have to enter the paths/logins on the FTP tab. Would like to know if this happened with any other applications and really appreciate any suggestions/inputs.

Please do let me know if you need additional information. I created a ticket with Automic Support and you can find more information inINC00217452

Thanks

Shravani

 

[Michael Pirson]

From what I remember as soon as the FTP tab in the task properties is modified it will break the 'link' to the base object. Based on this I would assume that each new workflow you would need to at least go in and hit apply on the task property ftp tab.

However, we use reusable FTP jobs in our environment and store all the relevant information in the Variables and Prompts of the parent level workflow. The variables are then mapped in the process tab to the attributes of the FTP job using the following:

https://docs.automic.com/documentation/webhelp/english/AWA/11.2/RA_FTP/4.0/Agent%20Guide/help_en.htm#RA/FTP/AWI/RA_FTP_Attributes.htm%3FTocPath%3DWorking%2520with%2520FTP%2520Jobs%7C_____5

[shravani_vedantham_6826]

Thank you for the prompt response.

Yes we make sure we hit apply when we modify the task properties. It still happens.

I would definitely try the approach that you are following on the FTP jobs. Hoping Automic Support will come up with a solution. 

[shravani_vedantham_6826]

Michael Pirson: As I was thinking about your solution, was wondering if you could send me the screenshot of your FTP tab how it would look ?how you are controlling each and every option on the FTP tab. Only if possible,

[Michael Pirson]

Here is a good post by Alex on the topic. From what I understand you would just need to change one attribute, the destination connection correct?

https://community.automic.com/discussion/comment/22544#Comment_22544

[Pete Wirfs]

We have had horrible experiences with overrides of RA-FTP objects in both AEV9 and now AEV11.   Workflows seem to retain override settings that don't necessarily display anywhere other than at run time.  But this is only a problem with RA-FTP objects.

All of our RA-FTP objects are custom built and are not re-used.  Consequently we are able to use this workaround when a modification is called for;
1. Totally delete the RA-FTP task from the workflow, SAVE the workflow, and close it. (to force it to discard the unwanted overrides.)
2. Make desired changes to the RA-FTP object and SAVE.
3. Re-add the RA-FTP task to the workflow.

This workaround is a pain when there are precondition/postcondition rules that also need to be applied.  But it has given us a much higher confidence in our RA-FTP modifications.

And as I write this, I am feeling kind of guilty for not having taken the time to work with support to force them to work on fixing this defect.  However in our case the scope is very small, and it is extremely rare that we need to modify our RA-FTP settings, making it hard to justify the time and effort.   I've worked with support on identification of other defects, and it can be quite time consuming.  (I have an open problem with them right now regarding a promptset defect that can break restart attempts, which is of much higher importance to us.)

I think that if you could add another workflow object between your parent process and your reusable RA-FTP object, then you could avoid this problem; your parent workflow would pass parameters to the child workflow, and I'm not aware of there being any problems with the handling of workflow-to-workflow overrides.  The problem is unique to RA-FTP objects.

[shravani_vedantham_6826]

Michael Pirson Thank you for the link. It looks like I just have to add what I need. I will try to use  this on our future File transfer flows.

Pete Wirfs : Thankyou for your response. We were following the same approach that you have mentioned above in AM V8.10. I wanted to make use of the Feature in AE by changing the taskproperties on the jobs and its not working. We may have to go back to the old method, if support doesn't provide a solution.

I was on a web-ex meeting with the support and couldn't reproduce the issue , it is so sporadic, wish I could re-produce.

I will also try the below approach just having that particular job in a workflow.

"I think that if you could add another workflow object between your parent process and your reusable RA-FTP object, then you could avoid this problem; your parent workflow would pass parameters to the child workflow, and I'm not aware of there being any problems with the handling of workflow-to-workflow overrides.  The problem is unique to RA-FTP objects."

Again, thankyou for your valuable suggestions. I will definitely post the solution if I found any !! Hoping I will.

[shravani_vedantham_6826]

Update: Looks like this has been taken care in version 12.0.2

I did not upgrade our system yet, but will do soon and let you know the results.

[shravani_vedantham_6826]

Correction - its12.0.4.