Web Dynpro JAVA developer attempting to unravel Environmental Compliance source code seeks guidance from EC NWDS Composition Environment specialist

[Former Member]

It frustrates me to have to ask for detailed instruction on this issue, but normal means of importing these Java-based EC software archives just aren't working in our NWDI system. We never moved our production WDJ applications to CE (like so many others we jumped straight from NW7.01 to NW7.3) but I'm doing my part to come up to speed on composition projects. No matter how we create the NWDI track and import the software archives and dependencies, we can't get to a state where we can successfully import a project (product?) from the Development Infrastructure into the Composite Explorer perspective.

I need to know specifically how I, an experienced WDJ developer with no exposure to CE, can take the five .SCA files that contain Environmental Compliance 3.0 and get the project into my NWDS 7.31 workspace in a workable state, on my local system, without NWDI. Actual code modifications can wait for the moment, I just need to analyze the classes and EJB's to identify where we might want to make enhancements, and where/how to use the provided Enhancement Spots. I've followed the links, downloaded the .pdf's, read the online help, stepped thru the tutorials - I've done my due dilligence. It's common knowledge that Composition Environment is no longer recommended for new development, and as the EH&S programs are converted to WDA there are even fewer resources to look to.

These specific types of pleas don't often return results, as I have learned over my years in this community, but nothing ventured-nothing gained, and I am no longer afraid of looking dumb or being scolded. I just need help.

As always, points will be awarded.

[junwu · Accepted solution]

is EC customizable?

just open the sca you have downloaded to see if they have source archive folder

[Former Member · Accepted solution]

Thank you so much for taking the time to respond.

My .sca files have BUILDARCHIVES containing .zip files, and DEPLOYARCHIVES containing .sca files. And the META-INF folder. Exactly what I would expect to see.

Oh no... there is no SOURCEARCHIVES folder.

Unbelievable.

Full points for correct answer. And face palm to me for fundamental oversight.

And on to the next question - how is the SAP customer expected to use extension points without the source code? I'm really hoping the answer to that question is not another face palm moment.

Said the "experienced" WDJ developer.

[junwu · Accepted solution]

normally you need the source code to do the customization.

maybe EC has a special framework, which allows customization without source code.

which document you are following that tells you can use the extension point to customize EC?

[Former Member · Accepted solution]

I have found no document that details how to customize this application, extension point or no. All I can find are references to their existence and encouragement to use them. Unless, once again the instructions are right under my nose and I don't see them, that is always a possibility.

This is quite a unique application. In a way, I am enjoying the analysis, tinged with a bit of resignation that this is a product at its EOL and not practical to learn in detail.

Thank you again for responding to my post!

[hofmann · Accepted solution]

SAP ships EC as-is. You do not gain access to source code and you cannot import EC into NWDI in such a way that a developer can customize it. The only customization allowed is by using extension points, but without source code access this isn't really helpful.

[former_member192152]

Hello Jennifer,

Actually add the package (SCA) in DI or import it in NWDS (local) does not allow you to make changes in the components. The SCA continues as read-only.

However, if you take a look at XEMMOD300SP00_3-10007499.SCA (unzipping it), notice DEPLOYARCHIVES folder in a series of SDAs. Unpacking the SDA "xem~permit~main~wd.sda" (which is the main WebDynpro application of EC), you may notice a file called src.zip, where you will find the source code.

That said, with the aid of a good WD Java Developer, you will be able to create a custom component software (able to customization), containing a "copy" of every component of Software Component Standard. Now just create copies of the EC Roles in SAP Portal and change the appointment of WD Java applications for custom applications.

This work is arduous and extensive. And in no way recommended. However, if you do not customize is not an option, and the cost of rework in case of future upgrades version of EC is acceptable, this is the best chance of achieving your goal.

Att,

Angelo

[hofmann]

There is a difference between you can do it and you can do it. SAP isn't shipping the SCA with the source code because you get EC as it is, customizing the applications is not allowed. There are some very specific extension points available, and these are the only ones where SAP allows you to do custom development.

If you want to develop a custom application that uses for instance the facility selector hierarchy, this is not exactly what SAP wants you to do. If you know the interface you can write your own WDJ app that uses the a facility hierarchy from EC. But taking the src.zip file and rebuild that into a usable format into NWDS is not what you should do. I'm not sure if this is even allowed.

[former_member192152]

Tobias,

The ability to customize the SAP is very relative. What will happen is probably void the warranty. Likewise held that occurs when a customization / copy of an ECC transaction.

Best regards,

Angelo

[hofmann]

It's a little bit different with EC. I already had some discussions with SAP about source code delivery of EC, and the intention is to not deliver the source code as the solution is not intended to be customized by anyone.

Therefore, you cannot customize a EC application, only extend it where extension points exist. To use EC functionality in a custom application: this is possible, but without source code available it is close to impossible.

[former_member192152]

I agree in part Tobias.

Because the source code is in the SCA within the src.zip file within each SDA.

What does not exist within that SCA Standard is the SOURCEARCHIVES folder. In that folder should be a file (the extension .dcsa) for each DC (component) that SCA Standard.

In short, yes it is possible to perform a reverse engineering...

1. Just import the SCA Standard in NWDS.
2. Note the name and type of all DCs, its dependencies and its public parts... yes, it's a lot of work, as there are many interdependent DCs.
3. Done so, create a new workspace in NWDS and create a new SCA in DI (custom), inside it create all DCs with the same names and types (and dependencies)... identical to SCA Standard.
4. And soon after, entering the SRC folder of each of these projects (DCs) and replace its contents with the contents of src.zip file that is contained within the SDA files within the SCA Standard.

That done, we will have an SCA Custom with all representative of the SCA Standard DCs, but editable.

I agree it is not nearly a good practice, or even that SAP indicate that this is done... however, it is possible yes.

Att,

Angelo

[hofmann]

Again, EC is shipped without source code because it is not allowed to customize the applications. Talk with the SAP EC team, they will confirm that.

[former_member192152]

Tobias,

I'm showing you the prints above the source code comes in SCA. I explained how to customize. I've done this customization.

Blindly believe in what you say and SAP succeed.

Big hug.

"The worst blind is the one who will not see."

[Former Member]

It's true that there are bits and pieces of source code to be gleaned from the SCA, but since these were WebDynpro classes there was little to no business logic to be found. The EC product development team did an excellent job staying within the MVC framework, so the WebDynpro code I uncovered was generally presentation layer logic and pretty much useless to me - writing a batch job. I presume the majority of business logic exists in EJB's, and that puts it far beyond my reach, both practically and ethically. Nice piece of obfuscating!

Still, by studying what I COULD see of the content and structure of the SCA files I learned a lot, nothing proprietary about the operation of the application, but quite the opposite - what I needed to do for my client didn't involve the Environmental Compliance application at all. What I REALLY needed to do was work with UWL classes and the Java Scheduler in NWA. The only thing I needed from EC was to read their task tables in the portal database, and that is easy enough using JDBC. Not morally ambiguous or legally shaky at all.

I was mildly surprised at first that customization of what I thought was original SAP application code was prohibited, and my attempts to acquire source code would be so vehemently opposed, but I get it now. Originating from a third party, purchased by SAP, unknown licensing conditions, who wants to risk litigation? No thanks. I can say, though, it was a great study exercise. At least I have a new appreciation of the Composition Environment.

[hofmann]

read their task tables in the portal database, and that is easy enough using JDBC. Not morally ambiguous or legally shaky at all

AFAIK even that is not allowed. The only application than gains access to the EC tables is EC. If you access it from your own application without using the EC interface you may be on the risk of violating some legal agreement.

The EC product development team did an excellent job staying within the MVC framework

You'll have to convince of that 🙂 The WDJ apps do not use a model.

[Former Member]

Thanks for the heads up about reading the EC portal tables. I think I'm OK in this area, though, because I am working with SAP and so far they support my design. And all I am doing is a SQL select, no inserts/updates/deletes or transactions.

You do make a point - I must withdraw my remarks regarding the initial EC product development teams application of MVC principles. I don't know whether they did or not, I was just saying I found no business logic in the attainable WebDynpro source code, so their secrets are safe from any possibility of reverse engineering by me.

[Former Member]

Angelo, Tobias, thank you so much for your wisdom and advice.

By the way, Tobias, about talking to the SAP EC team, I did (and I still am!)

[hofmann]

In that case, say Hi to them from me 🙂

[hofmann]

The business logic is encapsulated in the EJBs, but the WDJ apps do not use the EJBs as a model. Instead, they are simply imported and used a normal Java classes. I guess one of the reasons why EC isn't so happy in having people access the DB tables is the fact that EC does not use JEE persistency. EC comes with its own persistency framework and uses nothing what JEE 5 offers: no JPA, perstency.xml, Entity Manager, etc.

How the web services EC uses are coded is also interesting: looks like either manually created or with NWDS for NW 2004. But again: no EJB annotations used. Depending on the SP you are on, it can be of interest to see how the security checks for the web services are implemented.