Am I understanding this correctly, you want to build the relationships and create the "number of conductors" in the output database? Esri simple relationships are simply PK \\ FK values using your origin and destination fields.

There are a lot of ways to accomplish this, but if you are not working with 100s of thousands of rows, the feature merger is amazing. You can ask it to create a list and use the Origin and Destination columns as the requester and supplier. Once completed the parent will have all selected attributes of the child in list format.

This is just one of dozens of ways to accomplish this but I hope that it helps! As far as the multiple workspaces, that depends on how much work you want to put into it. I have had great luck with creating "steps" and then combining them all with a master workspace that uses a workspace caller in order of operation. This was of course before feature writers and the new caching options that Safe has given us. You can cache each step so you can test from that location.

Hope this gives you an idea!

RelatesToList.fmw

RelateTest.gdb.zip

@dellerbeck Thanks for the feedback and the example workspace and data! It is much appreciated.

"Am I understanding this correctly, you want to build the relationships and create the "number of conductors" in the output database? Esri simple relationships are simply PK \\ FK values using your origin and destination fields."

I don't think this is exactly right. I should have done a better job explaining the problem. I will provide some mocked up data/example (I am going to skip the feature mapping to primary overhead and underground part and just focus on the relationship part):

Say the input row looks something like this after it comes out of the attribute filter as primary overhead:

So, I want the writer to make one new row in the output primary overhead feature class. This will be the polyline of the conductor.

Then in the conductor info table, there will be three new rows. One for each phase.

With "objectid" as the PK and "primary overhead objectid" as the FK for the relationship between the objects. Now, of course, if the input row had only two phases, e.g. AB, then only two rows would be made in the conductor info table.

I don't know what the PK object id will be ahead of time as this is managed by esri. But it looks like fme will support this "single pass" workflow. This is the part I am currently stuck on. I have thought about loading all of the data and then going back and updating the relationships in a separate operation. But that would add time to my process. We are trying to keep the load time at a minimum.

Thanks for the tip on the workspace caller. I did not know that existed!

@fallingdog We have a couple of tutorials on working with Esri Geodb relationships and the attributes you need to set on the origin & destination feature classes . Introduction to Working with Geodatabase Relationship Classes and Writing Geodatabase Relationship Classes

I've attached a workspace (based on @dellerbeck 's data) that illustrates what you need to do (using a GeoPackage instead of Oracle as the source). Workspace (2019): create1tomrelationship.fmwt

Just to re-emphasize: FME uses the geodb_oid to make the join between the origin & destination feature classes. So geodb_oid must have the same value for the corresponding records in A_ParentClass & B_ChildClass (or CondctorInfo and PriOHElectricLineSegment)

Much clearer!!!! Sorry, I came from an electrical GIS background using FME. I LOVE ELECTRIC!! So let's have some fun here. As Mark (Insert true FME master here) has shown, working with 1:n relationships in Esri using FME is quite easy.

I attached a simple workspace that I think will really help you out. It looks at the phase of the Primary then uses a cloner \\ attribute manager to generate a "conductor unit". I know this is simple but it's just one example of how to do this. I know not all of the voltages or data will be exact, but hey it's still fun.

CloneUnits.fmw

@dellerbeck - Awesome! Nice to see other people with electrical GIS backgrounds here! And thanks for the workspace! I was easily able to apply it to mine to create the info rows. But the relationship is still killing me :(

@markatsafe - thanks for the workspace! Sadly mine is still not working. I have added to mine based on @dellerbeck workspace and yours. The only difference I see between yours and mine, in the relationship area, is the uses of ParentID. Because I am splitting up one row into a feature class and a table, I only have one source ID. So, I have used counters for the geodb_oid's (I have seen this done in some of the tutorials). But I am getting:

An error occurred while attempting to store a row into the table 'ConductorInfo'. The error number from ArcObjects is: '-2147221230'. The error message from ArcObjects is: {}

I was getting this same error before in the environment when I would just try and write out the primary overheads. I ended up deleting an annotation relationship and it cleared up. But now I can't get past it... even if I delete all relationships but the target one I still get it...

Looking at the screenshot of your workspace, not exactly sure what your problem is. Just to ask the not too obvious, was the relationship classes already created in your destination fgdb?

I support that approach of starting small and incrementally build from it. The Electric dataset is fairly complex and its always nice to isolate things that work as you build.