高级问题：由于我们现有的管道设计以及ADF V1（即通过输入数据集/切片）和ADF V2（通过触发器和活动链）如何管理依赖关系之间的根本区别，我们陷入了循环依赖问题。在ADF V1中，我们可以简单地通过将一个管道的活动的输出数据集用作另一管道的活动的输入数据集来建立跨管道的依赖关系。但是在ADFV2中，我们使用触发器来触发管道运行。通过触发器执行相同的操作会进入循环引用。
示例：
在ADF V1中：
管道： AGetData，AProcessData，BGetData，BProcessData -所有数据集的调度间隔为1小时。所有管道的开始时间都相同。 这里 AGetData 和 AProcessData 在逻辑上与实体A 和 BGetData 和 BProcessData 相关在逻辑上与实体B 相关。并且 ProcessData 管道在任何实体的 GetData 管道之后运行。
依赖项：
a。 AGetData 取决于以前运行的 AProcessData 的输出数据集-间隔为1小时。
b。 AProcessData 取决于 AGetData 当前运行的输出数据集，还取决于 BProcessData 中1个活动的输出数据集（不是最后一个活动输出数据集，而是输出在管道 BProcessData 之间的某些活动的数据集。 C。 BGetData 取决于 AProcessData 的先前运行的最终（最后活动）输出数据集和 BProcessData 的先前运行的最终（最后活动）输出数据集。
在ADF V2中：
管道：A和B。我们已将 AGetData 和 AProcessData 合并到A中，并将 BGetData 和 BProcessData 合并到了B.活动被链接在一起，以使 ProcessData 活动在 GetData 活动之后执行（在订购方面类似于ADF v1）。
此外，在ADFV2中，我们没有为每个活动创建单独的数据集。我们有2个数据集-分别指向Source和Destination-在所有活动中都可以重复使用。 在ADFV1中，我们为每个活动创建了单独的数据集。然后，我们使用这些数据集/数据切片在管道之间建立了依赖性。
此外，在ADFV2中，我们在DB的配置表中为每个管道维护活动元数据，并且在管道运行时，我们从该表中读取行并在ForEach Activity中执行这些活动（例如，复制，运行存储过程）。
此外，使用称为ExecutionLevel的列条目来管理链接/依赖关系。每个行都有执行级别，例如1,2,3，…，并且只有在先前的执行级别的活动完成执行后，才会运行一个执行级别的活动。相同执行级别的活动并行运行。这样，管道是由数据库配置驱动的，与v1相比，大多数事情都是动态的-（因为我们没有每个活动的单独数据集，并且UI中没有显示长管道）。
我们将每个管道执行记录在DB表中。在此处将其称为 ExecutionLogs 。这些日志捕获每个管道运行的活动完成，活动失败等。
现在，要说明如何维护ADFV2中的依赖性。
在上面的依赖项中：对于点a），滚动窗口触发器的自相关性会有所帮助。对于点b和c，如果我们尝试为管道A和B分别触发一个触发器，则会陷入循环依赖关系。
例如：T1触发A，T2触发B。
此处T1是自相关的，并且也取决于T2 –基于上述依赖关系（管道A的活动之一取决于管道B的活动输出） 另外，T2是自相关的，并且也取决于T1 –因为 B 依赖于上次运行的 A （这是循环依赖的来源）。在ADF v1中，通过输入数据集将相同的事物作为依赖项进行管理。
所以一种方法是：设置通过触发器的单向依赖关系（T1依赖于自身的最后一次运行，T2依赖于其自身的最后一次运行和T1的最后一次运行），并在管道A中具有“直到活动”，以进行检查（通过引用< strong> ExecutionLogs ），如果当前运行的管道B已完成执行管道A所依赖的活动。当我们从表中读取活动元数据并动态运行这些活动时，我们将管理额外的列以进行依存关系-例如，如果对于管道A的给定行具有列值，对于给定的行具有依存活动，那么在执行管道A时，在某个时候，它将检查这些依赖关系相关列的值。如果发现为任何行设置了值，它将运行直到活动–直到查询日志，即 ExecutionLogs ，以检查是否存在以下条目：管道B中的依赖活动的最新完成状态（最新运行可以通过 ExecutionLogs 表中给定管道的最大执行ID进行标识）。如果找到条目，则管道A将继续执行管道中的下一个活动，否则它将等待并在特定时间间隔后重新检查条件。
以上解决方案只是一种方法，但似乎不是一种更干净的方法。在ADF V2中管理这些类型的依赖项的任何想法都将非常有帮助。