Skip to Content

Usual
disclaimer first: Don’t do this (unless you work for SAP and can make this
change a standard feature) unless you really, really have to and can control
the change appropriately.

Middle of
winter here in NZ so too dark/wet/cold for us office workers to go Mountain biking
but not quite enough snow yet to properly open the ski season so a bit of time
to visit some aspects of SAP E-Commerce.

Recently we
performed a SAP E-Commerce B2B and B2C upgrade from CRM 2007 to CRM 7.0.

During this
upgrade we discovered a number of interesting changes where by interesting I
generally mean adding unnecessary complexity that wasn’t there before like the UI
framework from B2C to B2B or forgetting to add a X to a standard pricing FM
call to return catalog prices (how could that be missed during 70 pre-release
testing?)…or perhaps we are just getting too old and lazy to change with the
times?

Note to SAP
E-Commerce dev team: Some basic rules when you develop products / frameworks
that are sold to the market is that you need to provide configuration options…and
lots of them.

You could
almost say that a single hardcoded string or number in the code base is one too
many…unless the aforementioned piece is template code that you expect your
users to change. Also, pre-release testing: Having no catalog prices in the
released B2B shop. There is no way this should have passed testing as having an
E-Commerce site without prices for products is like…selling a car without
wheels…very hard to not spot if you try to use it.

To
illustrate this change between versions I use the following example of what was
done followed by how we feel it should have been done.

In
E-Commerce you can choose to either find 100% matching results or use drfuzzy
to give you fuzzier results. Obviously most customers would like some level of
fuzziness to be implemented to cover typos and most times return some search
results. As the description of how much fuzziness this search option produces
it has been a case of trial and error to see how well it has worked for the
customers (as no indication had been given on what level of fuzziness was to be
expected).

In this
specific case the fuzziness was turned on in 2007 as it seemed to still return matching
results and though no great effort was made to test the actual fuzziness it was
assumed that it would also apply some logic in the background to the queries.

Prior to
the upgrade a search using a product number returned the product that was the
exact match. This was what was expected. After the upgrade to 70 the same query
returned between 200 and 350 products. We spent quite some time trawling
through lots and lots of code until we found the “offending” line.

The class com.sap.isa.catalog.trexgen.TrexGenCatalogFilterVisitor

had changed ever so slightly…a couple of new lines had appeared in the source:

*// Note
#1456485*

entry.setFuzzySimilarity((float)0.6);

Hmm..interesting…reading
the note we found out that this fuzziness was introduced to make the fuzzy
search fuzzy as it defaulted to 1.0 which apparently meant no fuzziness…

Note to SAP
product test team: Who had fuzziness testing on their task list? Perhaps worth
re-visiting the original test cases as this feature was obviously turned off
until now.

Now, the fuzziness
value of 0.6 obviously creates the return of 300+ results instead of 1 but
shouldn’t the level of fuzziness be adjustable by the customers to match how
fuzzy they would like their results to be?

There is
nothing in the aforementioned class suggesting that this 0.6 would be a default
value that you could override with some parameter. So it looks like it is 0.6
or nothing (turn the fuzziness off completely).

So how do
we live with this change? Well, in our case, we don’t want to live with it and
the least amount of change we could achieve the desired result was to remove
this line of code doing the following: (Note: don’t do this change unless you
have a very strong version control and issue tracking solution in place or this
will become an issue in the future).

We removed

the class com.sap.isa.catalog.trexgen.TrexGenCatalogFilterVisitor from the jar sap.comcrmtcpcatapiassembly.jar

and renamed the jar to z_sap.comcrmtcpcatapiassembly.jar

After this
we re-created the class within our custom source tree (with the same name and
package) and commented out the offending 0.6 line.

This way we
were back at getting the search results we wanted.

What we
would hope the SAP E-Commerce team would do is that they would put this
fuzziness factor into XCM and allows us to modify it there (and if we use the
E-Commerce caching feature as well we could simply need to clear the cache to
have this value re-loaded).

Meanwhile

if you would like to do this yourselves so that you can try out different

values you can either re-compile the class mentioned before with your own

values to try them out or you could implement your own XCM extension (download

and modify config_data.xml and then upload it again):*ComponentConfig

componentConfiguration = FrameworkConfigManager.XCM.getApplicationScopeConfig().getComponentConfig(“personalization”, “drfuzzyconfig”);*

Properties parameters =
componentConfiguration.getAllParams();

*String fuzzinessfactor = (String)
parameters.get(“fuzzy_factor”);*

*//Then convert
this to a float and use it in the setFuzzySimilarity //method.*

This way
you can then in XCM modify this value at your will and see the results.

I won’t get
into the caching of E-Commerce as this is something you can trivially look up
in standard code.

Another way
would of course to put a breakpoint in the code around this value and then
during a debug session change the value…but you would still have to implement
one of these strategies to then adjust the value if 0.6 isn’t optimal for you.

Lastly
Aspect Oriented Programming would obviously give you a non-intrusive way to
change this…but it might be a can of worms you don’t want to open.

Meanwhile,
hoping to see this change in the standard code base in the near future.

Cheers

Kalle

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Dick Dijk
    Hi,

    I am using an older Java Engine (2004s), the B2C shop uses IMSCatalogBuilder instead of TrexCatalogBuilder. Here fuzzy search seems to work OK, although I hava no idea what value of fuzziness is actually used (I cannot set it anywhere).

    Do you know if switching to the TrexCatalogBuilder has any advantages, e.g. in performance?

    Kind regards,
    Dick

    (0) 

Leave a Reply