topic Re: WFA - Command updating reservation works but not in workflow in Active IQ Unified Manager Discussions

WFA - Command updating reservation works but not in workflow

LFueyo — Thu, 05 Jun 2025 04:11:07 GMT

Hello,

I've been working on a workflow used for Disaster Recovery Plans since a few days ago, and I must say that I'm stuck on something that I just can't understand.

In this workflow, I'm using the "Reverse Resync SnapMirror" two times. Unfortunately this puts two rows of reservation entries and the first one is never cleared even on cache acquisition, which is a little bit problematic if the workflow has to run again before the reservation expires. (and I wouldn't want a customer to have to clean specific reservations, let's keep it simple).

The solution I thought about was to force an acquisition on OCUM, right after the first "Reverse Resync" workflow, using the great commands from sinhaa . They work just fine if I execute them alone, or from a CLI, and they return no error in a workflow (in fact, I can even see that the data acquisition occurred in the data sources tab and on OCUM).

The thing is : the reservation tab is updated when I use them from a CLI or "test" them, but it's not if I used the commands from a workflow.

I checked that the inputs were the same, tried after clearing the Reservations and I always get the same result : the acquisition on OCUM and WFA happened (they are listed in the GUI and the rows from the cache database are updated) but didn't update the reservations.

(If it's a known problem for a few versions, I'm using WFA 3.0 with OCUM 6.2 and a CDOT 8.3)

Regards,

Lucas Fueyo.

Re: WFA - Command updating reservation works but not in workflow

rkiran — Thu, 04 Jun 2015 09:32:02 GMT

Hi Lucas,
Are you referring to 'Reverse Resync SnapMirror relationship' sample workflow ? Which command reservation tab are you referring to ?
Are they certified commands ? If not, can you attach the dar or paste the screenshot of reservation and verification code.

Re: WFA - Command updating reservation works but not in workflow

LFueyo — Thu, 04 Jun 2015 09:49:54 GMT

Hi,

Indeed, the workflow I'm talking about is the sample workflow. (same reservation script at least)

The source of the problem is conflicting reservations as described here, but a forced acquisition after the first reservation should resolve it.

I'm referring to the user specific reservation tab, and not the reservation scripts that you could find on objects.

Would it be possible to e-mail you the workflows ? That would be a lot easier.

Re: WFA - Command updating reservation works but not in workflow

rkiran — Thu, 04 Jun 2015 10:23:40 GMT

Yes, please send me the workflows

Re: WFA - Command updating reservation works but not in workflow

sinhaa — Thu, 04 Jun 2015 12:01:51 GMT

Hi Lucas,

You are saying that Entry for the command is not removed even after Refresh and OCUM acquistion?

sinhaa

Re: WFA - Command updating reservation works but not in workflow

LFueyo — Thu, 04 Jun 2015 12:31:21 GMT

Hi Sinhaa,

It's as you said, when starting the workflow here is the kind of reservation I have :

After the OCUM refresh and data acquisition in WFA via the workflow, the reservation is still the same way.

When I execute the acquisition via the same command outside the workflow (with the same inputs), it actually works :

EDIT : And the acquisition from the workflow should work, as it updates the cache database and I can see the events in OCUM as well as WFA on the right data sources and clusters.

Re: WFA - Command updating reservation works but not in workflow

sinhaa — Thu, 04 Jun 2015 13:02:54 GMT

Looking into this. I'll get back to you.

Re: WFA - Command updating reservation works but not in workflow

LFueyo — Thu, 04 Jun 2015 13:08:48 GMT

No problem, thanks for the fast answer. (and good luck)

Re: WFA - Command updating reservation works but not in workflow

rkiran — Fri, 05 Jun 2015 15:24:39 GMT

Hi Lucas,
The problem is not related to conflicting reservations. Here is the reason:
Cache data will not be updated for the reservations when the workflow is in execution.
WFA verification script (used to verify a reservation) gets executed only for the workflows whose job execution status is NOT IN ('SCHEDULED', 'PENDING', 'EXECUTING', 'PLANNING')). In your case, the workflow status is still EXECUTING while it is acquiring the OCUM datasource, and hence the Cache data will not be updated for the reservations in the reservation tab.

Re: WFA - Command updating reservation works but not in workflow

LFueyo — Fri, 05 Jun 2015 15:50:09 GMT

Hi,

Thanks for the good work, we now know where this strange behaviour came from.

What could I possibly do to resolve this problem ? (besides asking the user to do a cache acquisition after the reservation ?)

I can think of :

- Invoking the workflow via rest

- catching an snmp trap on approval points and invoking the commands forcing the acquisition if it's after a reservation

But I feel like we would be losing pretty much all the advantages of WFA as it would require an external script ?

The other solution I can think of would be to schedule the execution of the commands forcing the acquisition via another command in the workflow. This way, we could manage an execution of the acquisition something like 5 minutes after the reservation (and so when the actual workflow is either "waiting for approval" or "completed"). I don't know if it's possible though, I think I saw a scheduler workflow on the communities a while ago but that's pretty much it.

Regards,

Lucas Fueyo

Re: WFA - Command updating reservation works but not in workflow

LFueyo — Thu, 25 Jun 2015 07:34:07 GMT

Here is an update for all of those that are in the same kind of situation.

We solved the problem a few weeks ago (well, the problem being in WFA's core we couldn't solve it but at least we bypassed it).

Our solution being a little bit heavy as it requires an acquisition with OnCommand Unified Manager as well as the data sources, it isn't really suited for short / small workflows that need to go fast and are often executed.

Here is what we did :

- Invoke a rediscover on the concerned clusters via REST from the main workflow

- Schedule another workflow from the main worflow and wait for approval

This other workflow will force the data acquisition, and as it is scheduled and then executed in another workflow, the main workflow's reservation will be updated (the main workflow will be waiting for approval). Then, we just continue the execution of the main workflow.

I hope it'll help some of you, we unfortunately couldn't find any simpler way that was imperceptible to the end users.