Network Automation Software We are currently migrating this forum
over to our HelpSystems domain. Please
post all new threads in our new
HelpSystems Community Portal.
Post to the HelpSystems Forum
You are not currently logged on. You must be logged on in order to post. Log on
Or Create a new account
AutoMate Discussion
Decrease font size
Increase font size
Topic Title: FTP Delete step acting disabled even though enabled
Topic Summary: stupid BPA tricks
Created On: 06/18/2015 12:16 PM
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by JohnScott, on Thursday, June 18, 2015 12:19 PM

Answer:
I relate this for the good of the order, and don't need any troubleshooting response from NA...

Yesterday I discovered that a recently-created workflow that downloads files via FTP from a vendor's server, and then deletes the files from the remote server, was not actually accomplishing the delete part of that process. I copied several of the steps into a new workflow/new task to debug them. My first theory was that the workflow was using the old-style FTP Delete instead of the Advanced FTP Delete, and that maybe there was a difference and the vendor's server only liked the Advanced variant.

As I continued to tweak and re-run my test workflow, and watch the FTP log, it became clear that neither my original old-FTP step nor my new Advanced FTP step were sending anything to the remote server.

In desperation, I just disabled the steps that were acting like they were disabled, and added new steps, newly configured to do the exact same things, to the task. Both of the new steps send their DELE commands to the remote server and get the file deleted.

By best theory now to explain this is that there is some sort of invisible corruption that infected the original old-style step, and that corruption came along when I copied it originally from an older workflow into the current production workflow, and then into the test workflow, and then when I created the Advanced FTP step by copying the old style step and changing the options. If this was Microsoft, I'd suspect that even though all these steps were referring to the same FTP session name, that buried underneath the visible code was a reference to a GUID that differed in each workflow. But the AML for the copied steps that act disabled is identical to the AML for the newly-created steps that work, and the AML contains the name of the FTP session and not some GUID.

The lesson: when something doesn't work the way it is documented to work (and that you think you've had it work in the past), try just dragging fresh instances of the steps in from the Actions pane.

#LoveHateRelationships
 06/18/2015 12:16 PM
User is offline View Users Profile Print this message

Author Icon
JohnScott
Artisan (200-499)

Posts: 231
Joined: 10/27/2010

Answer Answer
I relate this for the good of the order, and don't need any troubleshooting response from NA...

Yesterday I discovered that a recently-created workflow that downloads files via FTP from a vendor's server, and then deletes the files from the remote server, was not actually accomplishing the delete part of that process. I copied several of the steps into a new workflow/new task to debug them. My first theory was that the workflow was using the old-style FTP Delete instead of the Advanced FTP Delete, and that maybe there was a difference and the vendor's server only liked the Advanced variant.

As I continued to tweak and re-run my test workflow, and watch the FTP log, it became clear that neither my original old-FTP step nor my new Advanced FTP step were sending anything to the remote server.

In desperation, I just disabled the steps that were acting like they were disabled, and added new steps, newly configured to do the exact same things, to the task. Both of the new steps send their DELE commands to the remote server and get the file deleted.

By best theory now to explain this is that there is some sort of invisible corruption that infected the original old-style step, and that corruption came along when I copied it originally from an older workflow into the current production workflow, and then into the test workflow, and then when I created the Advanced FTP step by copying the old style step and changing the options. If this was Microsoft, I'd suspect that even though all these steps were referring to the same FTP session name, that buried underneath the visible code was a reference to a GUID that differed in each workflow. But the AML for the copied steps that act disabled is identical to the AML for the newly-created steps that work, and the AML contains the name of the FTP session and not some GUID.

The lesson: when something doesn't work the way it is documented to work (and that you think you've had it work in the past), try just dragging fresh instances of the steps in from the Actions pane.

#LoveHateRelationships

 Category Survey
AutoMate BPA Server 8 version: 8.0.1
Windows version: Windows 2003 R2
Statistics
18258 users are registered to the AutoMate Discussion forum.
There are currently 0 users logged in.
The most users ever online was 5551 on 01/08/2018 at 11:11 AM.
There are currently 1348 guests browsing this forum, which makes a total of 1348 users using this forum.

FuseTalk Enterprise Edition v4.0 - © 1999-2020 FuseTalk Inc. All rights reserved.

Sitemap Network Automation Software Blog