Stop The Madness: Indexing keyword EECAs

[Adrian Crum-3]

I tried to find out why a data import for a bespoke (made-to-order)
manufacturer was taking WAY too long. Turns out it was keyword indexing
EECAs.

Each product has dozens of product features, and it also has a
manufacturer ID. The indexProductKeywords is called for the product,
each product feature, and the ID. As a result, one product takes several
seconds to store.

Then the BOM for each product needs to be imported. The
indexWorkEffortKeywords service is called for each work effort in the
BOM. Why do I want my BOM work efforts keyword indexed?

This is insane. Why would anyone set up EECAs like that?

I would like to turn those EECA services into jobs that run on a regular
basis, so real work can get done in real time.

What do you think?

-Adrian

[hans_bakker]

Hi Adrian,

For a large product load we disable the seca's  temporarily and after
the load enable them again...
When people enter new single products sometimes they try to find these
straight away.... under the current scheme is working fine....

sorry do not see the madness here....the end of a hard working day?

Regards,
Hans


On 01/14/2012 07:59 AM, Adrian Crum wrote:

> I tried to find out why a data import for a bespoke (made-to-order)
> manufacturer was taking WAY too long. Turns out it was keyword
> indexing EECAs.
>
> Each product has dozens of product features, and it also has a
> manufacturer ID. The indexProductKeywords is called for the product,
> each product feature, and the ID. As a result, one product takes
> several seconds to store.
>
> Then the BOM for each product needs to be imported. The
> indexWorkEffortKeywords service is called for each work effort in the
> BOM. Why do I want my BOM work efforts keyword indexed?
>
> This is insane. Why would anyone set up EECAs like that?
>
> I would like to turn those EECA services into jobs that run on a
> regular basis, so real work can get done in real time.
>
> What do you think?
>
> -Adrian
>

[hans_bakker]

forgot to mention, that re-creating keywords, these jobs already exist.....

On 01/14/2012 08:04 AM, Hans Bakker wrote:

> Hi Adrian,
>
> For a large product load we disable the seca's  temporarily and after
> the load enable them again...
> When people enter new single products sometimes they try to find these
> straight away.... under the current scheme is working fine....
>
> sorry do not see the madness here....the end of a hard working day?
>
> Regards,
> Hans
>
>
> On 01/14/2012 07:59 AM, Adrian Crum wrote:
>> I tried to find out why a data import for a bespoke (made-to-order)
>> manufacturer was taking WAY too long. Turns out it was keyword
>> indexing EECAs.
>>
>> Each product has dozens of product features, and it also has a
>> manufacturer ID. The indexProductKeywords is called for the product,
>> each product feature, and the ID. As a result, one product takes
>> several seconds to store.
>>
>> Then the BOM for each product needs to be imported. The
>> indexWorkEffortKeywords service is called for each work effort in the
>> BOM. Why do I want my BOM work efforts keyword indexed?
>>
>> This is insane. Why would anyone set up EECAs like that?
>>
>> I would like to turn those EECA services into jobs that run on a
>> regular basis, so real work can get done in real time.
>>
>> What do you think?
>>
>> -Adrian
>>
>

[Jacopo Cappellato-4]

There is a flag in the Product entity that can beused to prevent the creation of product keywords; unfortunately the flag is ignored by the eca associated to the features of the product (imo this is something we should fix).

Kind regards,

Jacopo

On Jan 14, 2012, at 1:59 AM, Adrian Crum wrote:

> I tried to find out why a data import for a bespoke (made-to-order) manufacturer was taking WAY too long. Turns out it was keyword indexing EECAs.
>
> Each product has dozens of product features, and it also has a manufacturer ID. The indexProductKeywords is called for the product, each product feature, and the ID. As a result, one product takes several seconds to store.
>
> Then the BOM for each product needs to be imported. The indexWorkEffortKeywords service is called for each work effort in the BOM. Why do I want my BOM work efforts keyword indexed?
>
> This is insane. Why would anyone set up EECAs like that?
>
> I would like to turn those EECA services into jobs that run on a regular basis, so real work can get done in real time.
>
> What do you think?
>
> -Adrian
>

[Adrian Crum-3]

Thanks Jacopo.

I noticed that flag, but I'm not sure that will solve the problem. I
wonder if we could make the keyword indexing service call async?

Ideally, the keyword indexing implementation should be made smarter, or
more configurable, or something. Right now it seems to take a brute
force approach and index everything.

-Adrian

On 1/15/2012 6:15 AM, Jacopo Cappellato wrote:

> There is a flag in the Product entity that can beused to prevent the creation of product keywords; unfortunately the flag is ignored by the eca associated to the features of the product (imo this is something we should fix).
>
> Kind regards,
>
> Jacopo
>
> On Jan 14, 2012, at 1:59 AM, Adrian Crum wrote:
>
>> I tried to find out why a data import for a bespoke (made-to-order) manufacturer was taking WAY too long. Turns out it was keyword indexing EECAs.
>>
>> Each product has dozens of product features, and it also has a manufacturer ID. The indexProductKeywords is called for the product, each product feature, and the ID. As a result, one product takes several seconds to store.
>>
>> Then the BOM for each product needs to be imported. The indexWorkEffortKeywords service is called for each work effort in the BOM. Why do I want my BOM work efforts keyword indexed?
>>
>> This is insane. Why would anyone set up EECAs like that?
>>
>> I would like to turn those EECA services into jobs that run on a regular basis, so real work can get done in real time.
>>
>> What do you think?
>>
>> -Adrian
>>