I'd tend to agree with Pierre here, following the {entity}Identification
pattern is probably a better approach long term simply because the
externalId pattern breaks as soon as you need more than one identifier. If
the likelihood of multiple IDs is low, then the {entity}Attribute pattern
might be a better approach.
But with that said, when customizing a system I'll typically just throw an
additional field on the entity and be done with it. It doesn't take long
to write a helper method get{Entity}ByExternalId(String) to hook it up.
Because there's very little business logic that OFBiz can attach to these
fields, the amount of time we can save developers by having these fields
available in advance is very small. That changes with the Identification
pattern because we can provide from/thru dating, enforce unique constraints
and regex patterns etc. which will save developers more time.
Regarding Facility, it's useful to have an external identifier when you're
integrating/syncing with a 3PL system or in general if you don't own the
facility that you're using. But that could be said of almost any table in
the system when you need to keep it in sync with another.
I almost wonder if a generic entity (EntityIdentification) would be a
better approach that contains something like:
- entityName
- entityId
- fromDate
- thruDate
- idType
- value
We could then provide a set of generic helper methods/services to perform
lookups and update values e.g. GenericValue facility =
getEntityById("Facility", "3PL", "123"). The CRUD services could use
another table (EntityIdentificationType) to help with enforcing contraints:
- entityName
- idType
- requireUnique
- validationRegex
The main downsides would be:
- Duplication with the current <entity>Identification pattern (confusion)
- Lack of foreign keys back to the entities being identified
- Largely unused pattern in general currently (I think only EntityAuditLog
is similar)
Regards
Scott
On Fri, 3 May 2019 at 00:33, Pierre Smits <pierresm...@apache.org> wrote:
> Current methodology of having the externalId field in the various tables is
> limiting the capabilities of OFBiz. With this an object can have only 1
> externalId value. However, it is quite feasible that an object can be
> associated with various external systems with each having a different
> externalId value. This is particularly true for the party entity.
>
> I wonder whether this is necessary for a facility. If a supplier has an Id
> value for one of the internally used facilities, why would the adopter
> care? Similar thoughts are on contact mech and shipment. But a good example
> and explanation for each may help.
>
> The external Id of a product is (as far as it is related to a product
> supplied by a 3rd party) captured in SupplierProduct entity. If the intent
> is to capture the product Id as it is used by a customer and other parties,
> then the same reasoning as used for parties (see above) applies. Why would
> an OFBiz adopter care what the external Ids of downstream parties are?
>
> The identification type SKU can't be used for this purpose, as it is
> intended to have a value based on internally used variation/feature
> combinations. I suggest reading up on [1]. The definitions used by either
> supplier, customer, etc. may lead to conflicts.
>
>
> [1] https://en.wikipedia.org/wiki/Stock_keeping_unit
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Thu, May 2, 2019 at 1:44 PM Suraj Khurana <suraj.khur...@hotwax.co>
> wrote:
>
> > Hello team,
> >
> > As far as my understanding, externalId in OrderHeader is used to save
> > orderId reference of any other system into our system.
> >
> > If this is the only case, we should also maintain something similar on
> > following entities as well as consistency and they will be in need in
> case
> > of a full-fledged integration with OFBiz environment with any other
> system:
> >
> > 1. ReturnHeader
> > 2. ContactMech
> > 3. Party (already exist)
> > 4. Facility
> > 5. Product (can be discussed, Identification type SKU can also do the
> > job)
> >
> > Please let me know your thoughts on this.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > Technical Consultant
> >
>
