Run different fields to parse thru common tools and ignore not present errors

Question

Packaged workbook attached.  Screenshot below.

In the sample there are 2 paths: A-Kits and B-Kits.  A and B can each be split into two separate flows Recurring (R) and Non-Recurring (NR).  The paths and sub-paths contain the same steps.  The main difference being that the name of the field being processed changes.

In the larger data set there will be records that hit each of these paths.   But subsets of the records may not have B-Kits or may not have Recurring or Non-Recurring Records.  This can cause errors.  The sample contains A and B Recurring records, but not Non-Recurring records.

Two questions....

1.  Using a macro / app / interface tools....  how can I minimize the process by passing the different types (A, B, NR, R,) through the tools rather than setting up separate runs for each scenario.

2.  How can the workflow account for a missing type (A, B, N, NR) without errors.  BTW (I have the Ensure Fields macros, but I did not add it to the workflow).

Help.  ...and thanks.

SampleMacroNotPresent.yxzp

hellyars · Answer

@danilangYeah that's what i ended up doing. The workflow is designed for the whole, it only gets troublesome when I try to run sub-sets.  I've have everything outputting correctly, I am just trying to figure out ways to reduce the amount of steps and tools.  Thanks for your help. .

danilang · Answer

Hi @hellyars

Consider using Ensure fields after each corresponding XML tool to ensure that the require downstream xml fields are present without causing the duplicate field name problem.

Methodically applied to all containers should allow you to properly process the files whether the children are there or not.   In cases like XML parse (23) where you're parsing for all children, you'll need to include all fields of interest in the following Ensure Fields tool

Dan

SampleMacroNotPresent(EnsureFields).yxzp

hellyars · Answer

@danilang  I ran into a real world problem with this approach.  Each parse tool creates the field required in the next step.  Introducing it before the parse tool that extracts it assumes it will be absent.  If it is present the extracted field conflicts with the existing field (created by the Text Input/Join or Ensure Fields) causing the next parse down the line to be pointed to a null field instead of the present field (as it now has a 2 appended to it).  The construct of the documents being parsed requires a methodical step by step -- as Alteryx is unable to handle parsing a field if multiple children and cousins have the same name (e.g, Name)  -- it tries to parse them all