[Extension("Demo Auditor")]
internal class Auditor : AuditorBase
{
	public override string Account(
		bool discarded,
		Parsers.Interface.IAccountParserProvider.IParser interfaceItem,
		Parsers.Target.IAccountParserProvider.IEditable.IParser targetItem
		)
	{
		var xml = new XElement("Account",
			new XElement("balance", interfaceItem.Fields.Balance),
			new XElement("productCode", interfaceItem.Fields.ProductCode)
			);

		return xml.ToString(SaveOptions.DisableFormatting);
	}
}

Note that in the end, the Auditor is an extension to the Hopp Runtime just like Reformatters, Unloaders etc. As such, you can

• Decorate it with an Extension attribute to decide how the extension should be named in the Extension Usage panel in the Portal Operations
• Provide parameter properties to enable parameterization of the extension in the Extension Usage panel in the Portal Operations 

<ItemGroup>
  <AssemblyAttribute Include="MigFx.Director.MigDirectorExtension" />
</ItemGroup>

[ExtensionType(ExtensionType.SourceAuditor)]
public abstract class Auditor : ExtensionBase<IAuditorContext>
{
  public abstract string Collect(bool discarded, string businessEntity, string name, XmlElement sourceXml, XmlElement interfaceXml);
}

public abstract class AuditorBase : MigFx.Director.Server.Export.Audit.Auditor
{
	public override string Collect(bool discarded, string businessEntity, string name, XmlElement sourceXml, XmlElement interfaceXml)
	{
		var sourceItem = SourceItem.Parse(sourceXml);
		var interfaceItem = InterfaceItem.Parse(interfaceXml);

		switch (businessEntity)
		{
			case "Account":
				{
					var interfaceParser = interfaceItem.As().Account.Parse();

					return (name ?? "Unnamed") switch
					{
						"Unnamed" => Account(discarded, sourceItem.As().Account.Unnamed.Parse(), interfaceParser),
						"Loan" => Account(discarded, sourceItem.As().Account.Loan.Parse(), interfaceParser),
						_ => throw new ApplicationException($"Unknown Name passed to the Account Audit collector: {name}")
					};
				}
			case "Customer":
				{
					var interfaceParser = interfaceItem.As().Customer.Parse();

					return (name ?? "Unnamed") switch
					{
						"Unnamed" => Customer(discarded, sourceItem.As().Customer.Unnamed.Parse(), interfaceParser),
						_ => throw new ApplicationException($"Unknown Name passed to the Customer Audit collector: {name}")
					};
				}
			default:
				throw new ApplicationException($"Unknown BusinessEntityName passed to Audit collector: {businessEntity}");
		}
	}

	public virtual string Account(bool discarded, Parsers.Source.IAccountParserProvider.IUnnamed.IParser sourceItem, Parsers.Interface.IAccountParserProvider.IParser interfaceItem) => null;
	public virtual string Account(bool discarded, Parsers.Source.IAccountParserProvider.ILoan.IParser sourceItem, Parsers.Interface.IAccountParserProvider.IParser interfaceItem) => null;

	public virtual string Customer(bool discarded, Parsers.Source.ICustomerParserProvider.IUnnamed.IParser sourceItem, Parsers.Interface.ICustomerParserProvider.IParser interfaceItem) => null;
}

Again, the generated AuditorBase implements the Collect from the abstract interface method and receives the 2 XmlElements from the Runtime and maps to generated, virtual methods that are called with the generated, strongly typed parsers for the source- and interface data.

The difference is that the generated base class contains 2 different virtual method overloads for the Account Business Entity, one overload accepts the typed source Item for Unnamed Account and the other overload accepts the typed source item for the Account named Loan.

The actual Source Auditor

Here's a very basic, sample implementation of a Source Auditor that only implements audit collection for both copies of Account by overriding the virtual Account method overloads. Since is does not override the default overload for the Customer, no Audit data is collected for the Customer Business Entity.

[Extension("Demo Auditor")]
public class Auditor : AuditorBase
{
	// Audit Unnamed Account
	public override string Account(
		bool discarded, 
		Parsers.Source.IAccountParserProvider.IUnnamed.IParser sourceItem, 
		Parsers.Interface.IAccountParserProvider.IParser interfaceItem
		)
	{
		var xml = new XElement("Audit",
			new XAttribute("type", "normal"),
			new XElement("balance", sourceItem.ExtractionMap.Account().Fields.Balance),
			new XElement("ProductType", sourceItem.ExtractionMap.Account().Fields.ProductType)
			);

		return xml.ToString(SaveOptions.DisableFormatting);
	}

	// Audit Loan Account
	public override string Account(
		bool discarded, 
		Parsers.Source.IAccountParserProvider.ILoan.IParser sourceItem, 
		Parsers.Interface.IAccountParserProvider.IParser interfaceItem
		)
	{
		var xml = new XElement("Audit",
			new XAttribute("type", "loan"),
			new XElement("balance", sourceItem.ExtractionMap.AccountAsLoan().Fields.Balance),
			new XElement("ProductType", sourceItem.ExtractionMap.AccountAsLoan().Fields.ProductType)
		);

		return xml.ToString(SaveOptions.DisableFormatting);
	}
}

In both overridden Account methods, the Auditor collects the ProductType and the Balanace from the sourceItem = the data that was extracted from the Staging database for the Account.

The difference between the 2 overrides is that the first one deals with the extraction map of the unnamed Account and the second one deals with the extraction map of the Loan account.

Important note

In order for your Source Engine to be enumerated by the Runtime extension discovery process, it is vital that the assembly has been decorated with the MigDirectorExtension attribute. This is done by adding the attribute to an ItemGroup element in the SourceEngineCustom.csproj file:

<ItemGroup>
  <AssemblyAttribute Include="MigFx.Director.MigDirectorExtension" />
</ItemGroup>

Conclusion

 The Runtime and the generated engine code work in unison to make it easy to implement Source- and Target Auditors and have them called by the Runtime when the engines have processed each Business Entity.

Implement your Auditors by overriding the relevant virtual methods in a class deriving from the generated AuditorBase in each engine.

When you override a method in your Auditor for a  specific Business Entity, the generated infrastructure will pass the migration data to that method a strongly typed parsers allowing you to inspect the migrated data in a name and type safe manner.  

You auditor then return a string representation of the collected audit data to the Runtime. The Runtime will then store audit data next to the Business Entity and handle all housekeeping of the audit data in connection to reiteration of the same Business Entity.

So, this is the collection of audit data. But that is of course only half the story. In the next article we will explore how you can get the audit data out of the Runtime to serve your reconciliation infrastructure.