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

[hellyars]

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. 

[danilang]

Hi @hellyars 

One way to fix this is to make sure that the fields exist where required.  In the example, I used a Text Input tool to Add in the fields that are missing downstream. The following Select tools are to force the required field types, since older version of Alteryx defaulted empty fields to Booleans.  There are no records in the new Text Input tools, so the union tools just add the field definition if it's not already there.  This is essentially what the Ensure Fields macro does, but not everyone has access to the CReW macros.  

There are two of these constructs in the sample illustration, because the Transpose tool changes the schema of the incoming dataset, so you need add in whatever fields might be missing after the schema change

There are other ways that you can accomplish this including using embedding the problematic containers into a macro and and using a control parameter to disable the containers if the required fields don't exist.  See my response to this post for an example of this

Dan

[hellyars]

@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

[danilang]

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

[hellyars]

@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. .