You are viewing limited content. For full access, please sign in.

Question

Question

Replicating Entries between Multiple Repositories with Workflow

asked on February 21, 2018

Good Morning All,

I am trying to perform what I expected to be a simple task, but is proving otherwise.  I have 2 repositories.  In a single workflow, I want to start with a conditional sequence based on which repository the starting entry was located in.  I then want to replicate the entry to the other repository.

What I'm seeing is that even though Workflow is monitoring both repositories, it appears the starting entry defaults to the first connection profile in the list.  This gives me a "Starting Entry Cannot be Accessed by the Source Repository" error on the other activity and won't let the workflow be published.

Here is a screenshot to clarify:

I could split out into multiple workflows, but I would like to keep them together, unless I am running into a Workflow limitation here.

Thanks,

Jason

 

0 0

Replies

replied on February 21, 2018 Show version history

Never thought of trying something like this, but could you add a Find Entry Activity that takes place in the secondary flow prior to the replicate activity and target it with %(Entry ID), then in your replicate activity, target that? Pretty sure you will need 2 separate flows though.

 

 

0 0
replied on February 21, 2018 Show version history

Hi John,

Thanks for the thought.  I tried this as a workaround and it does indeed work.  Many thanks for the suggestion.  I am interested if anyone from LF can identify why the find entry activity has to be used unnecessarily to facilitate the functionality.  This certainly feels like a limitation.

 

Thanks,

Jason

0 0
replied on February 21, 2018 Show version history

I think the important question is how would you get around this limitation? Dynamic profile selections sounds good on paper, but I don't think it would be as easy to implement as one might think.

You have to consider that the workflow really does need a "default" connection profile to prevent errors and to deal with starting entries unless there is something else telling it what connection profile to use.

Another consideration; if you have two or more profiles, how/when would the workflow know which one should be used as the default?

I suppose one could say that it can use the monitored repository that triggered the workflow rule, but how would workflow designer validate that there is a connection profile for each monitored repository?

What if you have more than one profile for the monitored repository? For example, some of my workflows have two different connection profiles with different access to the same repository so we can better audit/control workflow activity.

I'm not saying it wouldn't be possible or that it wouldn't be useful, just saying that previous discussions with LF engineers/developers has shown me that these things usually end up being a lot more complicated then they might seem from the user end.

0 0
replied on February 23, 2018

This is by design. Activities (except for Replicate Entries) have a single connection profile. By default, that inherits from the first profile in the workflow.

In your case, say the workflow starts with an entry from LBCHOffice. The Conditional Decision ("Which repository has changed?") will try to evaluate its conditions against the LBUSOffice profile because that's the default one. Since the entry is not from that repository, it fails.

Find Entry, with a profile set to the other repository, finds the right entry and provides its properties as tokens. To make this path work, you've also had to update your conditions to use this new set of tokens, which are now repository-agnostic.

That said, if all you're doing is replicating entries between repositories, 2 workflows with their own starting rules would be somewhat more efficient. Find Entry and condition evaluations add some processing overhead (mostly negligible, but possibly adding up at high loads).

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.