WCEM: Public Parts and DC dependencies

[WolfgangSattler]

In the last days and weeks we saw a lot of questions regarding public parts and also regarding class loader issues in WCEM extensions.

Therefore I give here a short overview about the required DC dependencies you have to maintain if you create new or enhance already existing modules.

Actually the most import point is to understand the difference between Build Time and Runtime dependencies.

For the standard module part DC's (like Metadata, UI and BO part) only the Build Time dependency is relevant.

Let's take a look to an example of a catalog extension:

In this example you see already a lot of importing things:

• Only use PublicRestricted, PublicStable and ExtensionRestricted and ExtensionStable parts from SAP DC's.
• Never ever use any assembly parts here
• Internal parts are only allow for SAP internal unit tests
• Add the DC wec/frw/tc/core to have access to web channel framework functionality

If there are still SAP classes missing in SAP public parts, which should be available for extensions, then please raise an OSS message. This is an error, which has to be fixed by SAP.

Important: The SAP public parts are only relevant for the Build Time!

Your DPU DC now defines the runtime dependencies.

Please be aware that every module DPU has its own class and therefore only know classes to which a runtime dependency is maintained. Therefore your DPU should have dependencies to the following DC's:

• DPU of the module you extend
• the framework "module" wec/frw/tc/core/app, if framework functionality is used
• DPU's of any module, which you are using directly

Beside this a DPU should than only include your assembly parts.

Never ever deploy SAP assembly parts with your DPU's.

If you are using JSF objects directly you have also to add the JSF library in the application-j2ee-engine.xml:

<!--  JSF 2 Implementation -->

<reference reference-type="hard" prepend="true">

        <reference-target provider-name="sap.com"

            target-type="library">wec~frw~tc~jsf~lib</reference-target>

</reference>

Please use for all other references the DC dependencies instead of entries in the xml.

I hope this blog helps you to create more easily your own modules in the future!

[daniel_ruiz2]

Hi Wolfgang,

"If there are still SAP classes missing in SAP public parts, which should be available for extensions, then please raise an OSS message. This is an error, which has to be fixed by SAP."

Did you notice that raising an OSS message is REALLY painful? - Wouldn't it be just much easier SAP provide the test suite so people responsible for extension (developers like me) could in fact also fix your test suite and attach a sample test project into OSS with a broken test that you would look at?

Look around and you will notice this process is rather similar alongside many projects that you can actually "report an issue".

Release the tests as another SCA file if you want, but release the tests... Everyone that extends the solution need those as much as you need to ensure SAP code works is ok.

Regards,

D.

[WolfgangSattler]

Hi Daniel,

Unfortunately I didn't get how deliver a test suite could fix the problem of missing entities in the SAP public parts.

I see that raising an OSS message is quite cumbersome and maybe too much overhead for such straightforward issues.

I will check internally if we could maybe establish a leaner solution to fix public part issues.

Regards Wolfgang

[daniel_ruiz2]

Hi Wolfgang,

Delivering a Test Suite won't fix any issues, but rather will make everyone's life easier:

1. Ensure SAP tested what they claim to have tested: Assumption here is, case there is no Test Case for a given issue, there was no test of that from SAP.

2. Extending the 'problematic' Test Class adding up a test method (or multiple) proving what's wrong with SAP delivered software;

3. Having an OSS message raised with a Test Case attached could go 'directly' to the development team since it's a test case and describes 'precisely' what's the issue is about.

4. These test cases from SAP could also be used as a basis on customers test to ensure no custom code broke SAP delivered functionality.

I mean, I could go here for a while pointing out 'benefits' of having such tests available - Case 'we don't want to inflate SCA size', put them in a separate SCA and whoever wants to use them (and know how to use them) can take advantage or having unit tests.

IMO, there is no good reason to not have tests in your software; in fact, it's terrible... It's a bit pointless for people extending WCEM code their own tests when one can easily break SAP namespace functionality and never have a clue they in fact did.

Would be REALLY nice if you could put up a word there: Make it less painful and you will have more people helping SAP to fix issues.

(now you can imagine changing a public part takes 10 seconds but we surely cannot say the same for an OSS message.....)

Regards,

D.

[WolfgangSattler]

Hi Daniel,

I see your points. But we saw also additional effort on our side to deliver also out test suites. Therefore we decide against the delivery.

Nevertheless I will forward your request to the Product Owner.

Regards Wolfgang

[daniel_ruiz2]

Hi Wolfgang,

"But we saw also additional effort on our side to deliver also out test suites. " - Not too sure what that means - either SAP has the tests and run them or it's fairy tale.

I'm 99% positive I would never see a piece of SAP software released with Tests (because that would prove the software was actually tested) - but I will keep on trying.. and thanks for passing the word, pretty sure all real developers would thank you for that.

:smile:

Regards,

D.

[Former Member]

Hi Daniel,

It might sound strange to you, but there is indeed additional effort in delivering tests. Although I personally would also really like to see this. But actually there are good reasons for not doing so.

One little example, we use Open Source within our tests and as you probably know, there might be some restrictions when delivering code bundled with Open Source.

I personally can not understand why you doubt so much the existance of these tests. It should be 100% clear that any more or less serious software project contains tests.

But if you still think they are a fairytale, even better - I always wanted to be part of a fairytale :smile:

Best regards,

Ralf

[Former Member]

I find it interesting that we need to add this JSF2 implemetation everywhere, Almost all of our DPU's have view components(ui) modules and use WEC/JSF tag implementations. Surely this could be referenced 'hard' inside some sap core dpu ...

<!--  JSF 2 Implementation -->

<reference reference-type="hard" prepend="true">

        <reference-target provider-name="sap.com"

          target-type="library">wec~frw~tc~jsf~lib</reference-target>

</reference>

Note: If you don't include this it still compiles but when you try to use FacesContext anywhere you will retrieve a null pointer.

[Former Member]

Hi wolfgang.sattler

All this also apply to previous web channel releases and not only wcem !?!?  I´m implementing a custom icss scenario where my home/ext form beans are not accesible from web/icss_b2c jsp´s due to an access restriction, i´m thinking in create a PublicRestricted part with the resources.

[WolfgangSattler]

Hi Isaac,

With ISA we have no DPU's and also not such strict rules for the naming of the public parts. Therefore this only valid for WCEM.

Regards Wolfgang