Epicor BPM SO.Master Update pre processing add customer BO Service

Epicor ERP 10
, , ,
1

Hi Folks,

I am getting following error when I try to add Customer service in using and Reference and enable and click save. I am doing in SO.MasterUpdate method Pre processing. Any idea what should I do?

Error:

There is at least one compilation error.
CustomizationAdapter.cs(613,30): error CS0433: The type ‘ETCAddrValidationTableset’ exists in both ‘Erp.Contracts.BO.Customer, Version=10.2.200.0, Culture=neutral, PublicKeyToken=5d3fa3c7105d7992’ and ‘Erp.Contracts.BO.SalesOrder, Version=10.2.200.0, Culture=neutral, PublicKeyToken=5d3fa3c7105d7992’
CustomizationAdapter.cs(9,142): error CS0738: ‘SalesOrderSvcCustomization’ does not implement interface member ‘SalesOrderSvcContract.ETCValidateAddress(int, int, int, out bool, out bool, out string, out bool)’. ‘SalesOrderSvcCustomization.ETCValidateAddress(int, int, int, out bool, out bool, out string, out bool)’ cannot implement ‘SalesOrderSvcContract.ETCValidateAddress(int, int, int, out bool, out bool, out string, out bool)’ because it does not have the matching return type of ‘ETCAddrValidationTableset’.

2

That’s a limitation in BPM Method Directive as same table name cannot be referred by added service. Mainly I get this issue with SerialNumber table. Try with either Data Directive or customisation.

3

When you get to 10.2.500+, you might be able to do a lookup with an Epicor function. You can name your datasets whatever you need and avoid adding the second service.

1 Like
4

I raised this issue with Tony Wilby 5.5 years ago back in 10…0.704 Feedback from development team.

This is a known complication with how tablesets are exposed in ICE/E10 (and E10.1).

  1. All tableSets in all contracts are exposed in a single namespace (Erp.Tablesets)
  2. If two BOs expose a table with the same name (which may or may not have the same structure) or two BOs return a tableSet with the same name (again, those tableSets may have different structure), then there’s the name conflict if such contracts are added into a single project.

Compiling a directive (or customization, i.e. all directives on a method) referencing conflicting assemblies (and that includes the contract assembly of the BO for whose method the directive was created), fails.

In 10.1, Invoke BO/Fill Table by Query/Update Table by Query also require that the target type be visible during compile, with the consequences of the directive failing to compile if a conflict is encountered.

Currently, there’s no way around it through the BPM UI.

One possibility for the customer to overcome such conflict with existing code is to create a custom assembly which would act as an adapter for one of the conflicting contracts by exposing different set of types (one not conflicting with another referenced contract by name) and reference and use it from BPM directive. The downside is that when the used part of the contract for which the adapter was created, changes, the adapter may need to be adjusted, or a the least – if the contract from the new build arrives, the adapter will need to be recompiled.

Another possibility is to implement the directive in a C# assembly (and resolve the conflict there, see below), then use Invoke .NET Method action to call the code. I have to mention that directive’s code generation and execution environment evolve over time, so, just taking the generated source once will mean updates may be required later on.

When application developers encounter such a conflict, they use the functionality available in C# projects (I have to mention it is available for a completely different purpose) – external aliases (this can be used to resolve the conflict when implementing an assembly for Invoke .NET Method) – extern alias - C# Reference | Microsoft Learn

Long-term, I believe, we should consider the way of avoiding such conflicts when generating contracts.

SCRs describing such cases exist for BPM and for General Framework.

5

@Mark_Wonsil I agree that with Epicor Functions, I can convert most of my customization which has this issue.

1 Like