cancel
Showing results for 
Search instead for 
Did you mean: 

WCEM 2 - Module IPC - how to extend VMC Classes?

daniel_ruiz2
Active Contributor
0 Kudos

Hi,

I'm hope someone can bring me light on this one.. I've thought how to start describing the issue, and the best way I can put this " if you are a Java developer, have a look into the back-end services classes or bo classes... you will understand my pain ".

I'm facing a wall trying to make Pricing work properly while in the Catalog - and by working properly I mean doing the two extra miles that is not "coded" in those 10,000 lines classes scattered around the module.

Having a look how the function module calls work, I can only assume based on the fact its are calling a lot of 'deprecated modules' (Java Function Modules inside VMC) people in SAP was either too lazy to do it properly or they "forgot" to mark Java Enable Functions as not deprecated and also all the packages in the CRM.

Since the Catalog / IPC module in WCEM does not really use the 'standard' (and I don't like this word) function modules that are used during order maintain, we lose a lot of custom developed code in the item extension badi implementation that is used in the access sequences and inside the custom developed requirements, formulas and so on.

While I understand the fact a call to ABAP is required (even to reach directly the VMC, which is also super dumb if you ask me), I would like to maintain the "only one call is required" approach for speed - this way, it's in my understanding that an override on the SPC_CREATE_ITEMS function would be in place where I can perform the same that the BADI CRM_COM_COND_BADI performs and only them dispatch an updated version of the itemAttributes to VMC // IPC Classes.

Does anyone have any material about how to re-implement or extend classes (also, the SAP source code) contained in /0SAP/AP_SPC_DOCUMENT_IMPL module inside VMC?

Otherwise, does someone knows how could I make the IPC module call the ABAP stack (with correct back-end users) and only them dispatch the result to VMC?

I will grant points to anyone who gets 'close' of providing me any good information - SAP documentation about the old "Java Remote Methods" is non-existent or very hard to find.

D.

Accepted Solutions (1)

Accepted Solutions (1)

christoph_hinssen
Active Participant
0 Kudos

Otherwise, does someone knows how could I make the IPC module call the ABAP stack (with correct back-end users) and only them dispatch the result to VMC?

Do you talk about the WCEM IPC module?

Then: Create an ABAP wrapper for Z_SPC_CREATE_ITEMS, do the required additional calls and then call SPC_CREATE_ITEMS in VMC.

This you can do via eai-config.xml, supposed the signature is the same.

(WCEM does not care whether RFC's are Java or ABAP)

Best regards,

Christoph

daniel_ruiz2
Active Contributor
0 Kudos

Hi Christoph,

I thought about that.. but then again, I'm just not 100% sure if this would be the best approach (thou I thought it would be good enough) - Are you aware of any issues I may face during createBackEndObject() in my extended BE class (wcem/ipc module, bo, custom namespace).

And in regards eai-config.xml - I'm not too sure where this XML lies in the DC's, I can do a full checkout and look for it.. do you know if there is more than one file with this name across all WCEM DC's delivered by SAP?

Also, do I have to execute the call function (to call Java inside VMC) with an specific destination like order maintain does? (I've seem something like gv_vmc somewhere in the SAP ABAP code...)

Cheers,

D.

christoph_hinssen
Active Participant
0 Kudos

Hi Daniel,

You can extend eai-config.xml (standard version in sap.com_SAP-WEC-FRW/dev/inactive/DCs/sap.com/wec/frw/mc/wcf/_comp/
src/sap.wcf/com.sap.common/common)
in any custom module DC, of course then you need

<config-file namespace="customer" part="<part>" type="eai-config">eai-config.xml</config-file> in your metadata.xml.

And you need to add the replacement to the connection factory

<managedConnectionFactory name="JCO" className="com.sap.wec.tc.core.backend.sp.jco.JCoManagedConnectionFactory" version="1.0">
<params>
<param name="fm:name of standard function modue" value="new name of wrapper module"/>
</params>
</managedConnectionFactory>

Why would you expect issues in createBackendObject? From the WCEM point of view, it does not matter whether we call VMC function modules or ABAP ones. No difference in connection handling.

From ABAP side you can call VMC modules also like this:

CALL FUNCTION 'FGD_DETERMINE_CONDITIONS' DESTINATION ''

daniel_ruiz2
Active Contributor
0 Kudos

Hi Christiph,

Will take a look tomorrow when I have the code in front of me. I think it can actually work...

I had an impression there was just one eai-config.xml but I wasn't 100% sure.. would eventually find out tomorrow with a full checkout - but thanks for pointing out the location.

" CALL FUNCTION 'FGD_DETERMINE_CONDITIONS' DESTINATION '' - is there an specific destination to call Functions inside VMC or the ABAP will delegate it seamlessly?

Cheers,

D.

christoph_hinssen
Active Participant
0 Kudos

Yes......If you call an VMC function module with blank destination like in the snipped above (but DESTINATION key word is needed), ABAP will delegate.

Best regards,

Christoph

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Daniel,

this is a well know situation and I already made another person here aware about the situation:

To be able to access at all any information, you need to go to Tx /n/SAPCND/UEASS. Here you actually map the SAP name to your key value, that you use within the IPC to access the value.

Now another issue, you can only access information that have been pushed from the shop to the IPC  - there a just a handfull values at all. It does not matter if you need a specific value and you simply add the value within UEASS. If this value is not available, then you must enhance within the Shop also the interface to pass additional values. Sounds strange, but there is no alternative!

In other words, your BADI will not be considered for the IPC call if the call came from the WCEM.

I would NOT recommend to perform any RFC call within the Z_Function. You will be warned everywhere, that RFC calls in the pricing should not happen. If you do it in the Z_ Function, that it would be equal to doing it in the Java class.

You should do such RFC call (if really necessary) in the WCEM itself and push the additional values into variables, which then will be accessible within your IPC Java class in the VMC. This RFC call should not happen everytime you perform a pricing, try to do it once and cache the results. If you do it every time, then you might run into a dramtic  performance issue - this also would then effect yoru backend system (CRM & ERP), which is further more effecting the whole business.

I know it sounds in first place the same like doing it in the Z_ function or WCEM, but in WCEM you have a far better access & control to information & sessions and hence able to minimize the actual RFC calls.

There are alternatives for avoiding the RFC calls. Some pricing implementations are relying on RFC calls whilst you actually able to avoid those by pushing data into tables and access them with the access sequences. RFC calls are just easier, because you directly access the information - but this is not good at all.

daniel_ruiz2
Active Contributor
0 Kudos

Hi Andreas,

Well, one additional call is not what I'm looking for. I know it's one call and I may be able to create dynamic cache but it's simple one more call which I think should not exist. (and I will not cause overhead because we moved on from ISA thanks God!)

I'm not 'following' why you mentioned UEASS as I have no issues with Pricing Procedure implementation neither how IPC works in the Basket - it's more, catalog/ipc modules call directly VMC not really passing thru BADI's in CRM where a lot of the fields are populated to be later used and this is what causes the problem.

Also, I'm not too sure if you did understand the problem I'm facing:

I could extend catalog/ipc in WCEM and add another key/value pair in the itemAttributes Map, but this does not solve my issue since the code to populate a lot of Z fields are already coded in ABAP, and some stuff use ERP code.

Case for instance, the solution is Java "only", I would also need to remove all the extended code in the BADI because I would never allow to have 'duplicated' code laying around (one version for Java, one for ABAP) because WCEM treats catalog/ipc differently than Basket.

And..... I would "LOVE" to see "any" documentation about the Java Functions that catalog/ipc is calling inside VMC - simple documentation, any documentation to be honest... the comments in the classes of ipc module (wcem/ipc on sap namespace) are just a bummer and it kind states how 'frankstein' those back-end classes really are... (and 'no comments' to whoever let such code pass to be use for Production)

PS: I cannot cache the results since I depend on the Basket items to re-price catalogue items, also how many Products the user is actually 'modifying' in the Catalog Page (Quantities and UOM's) - reason why I'm more than concerned with performance.

Cheers,

D.

Former Member
0 Kudos

Hi,

first of all, you need the "Pricing userexit Manual", which contains your list of classes & interfaces (https://service.sap.com/~sapidb/012006153200000081802008E/PricingUserexitManualV104.pdf)

You probably need to get more specific with your situation. You have values in ERP, which you get to CRM? You are accessing BADIs directly in your pricing or just a specific filled DB table  (=> nobody cares if a BADI is called here somewhere before)?

As I am saying: the calls to CRM/ERP & Web-Shop to IPC are two different building sites.

First of all I am not understanding your issue why you need to know the amount of products in the basket and especially what the status of all products in the product  catalog page do have?? It's sounds for me more like, that you have a major design issue in your pricing process.

What kind of details are you pushing to the IPC? You should be able to cache values, if you need to provide informations like "the address of the BP", "customer group", "etc. but if you MUST call a RFC function with the exact number of the articles in the basket, then something is completely wrong.

As I said, you either have to push everything into a table and read it out using the access sequence (especially important if you do complex stuff), or you do it on fly (but only kind of static details because of performance issues).

In your case I have the feeling you might have to sit down with your client and discuss a redesign of the technical approach of the pricing.

If you like to avoid "duplicates", then you have to design your RFC function this way, that you can call it from Java & ABAP for pricing!

I am sorry for not giving you a kind of answer of "Yeaa, that easy.. do that". This pricing process is powerful, but is coming with some handicaps you need to consider in your design to guarantee a good performance.

daniel_ruiz2
Active Contributor
0 Kudos

Hi Andreas,

It's not that.. you are not even on the same page here, Christian is following though with good inputs.

" First of all I am not understanding your issue why you need to know the amount of products in the basket and especially what the status of all products in the product  catalog page do have?? "

Products in the catalogue are priced "ALONE" - HUGE mistake. Also, it's priced vs 1 QTY / Main UOM Defined in MDM. So it doesn't matter if the user adjust the quantity in the catalogue to " 2 ", still shows " Unit Price " - ANOTHER huge mistake.

I'm not too sure how much you know about pricing in general, I don't want to pull that thread, but I will give you two words: "Group Conditions"

" I am sorry for not giving you a kind of answer of "Yeaa, that easy.. do that". "

I kinda asked "documentation" and "approach" - you really went too far... I don't want an answer, I'm more concerned if I should throw all SAP "catalog/ipc" code on the garbage and start from scratch or if I can actually salvage something from that module.

Cheers,

D.

Former Member
0 Kudos
Products in the catalogue are priced "ALONE" - HUGE mistake. Also, it's priced vs 1 QTY / Main UOM Defined in MDM. So it doesn't matter if the user adjust the quantity in the catalogue to " 2 ", still shows " Unit Price " - ANOTHER huge mistake.

Are you changing just the Quantity or also the UoM on product detail or prodct list? Changing just the quantity would not make sense, because your actual prices are getting calculated thereafter in the basket. If you would change actually UoM, then this is another situation e.g. if the Palette does have a different price as equivalent amount of pieces. 

Anyway, we are going here a different direction now. Initially you wanted to figure out how to pass extra details to the IPC, now i talk more about WCEM itself and of how & when prices are displayed/updated.

I kinda asked "documentation" and "approach" - you really went too far... I don't want an answer, I'm more concerned if I should throw all SAP "catalog/ipc" code on the garbage and start from scratch or if I can actually salvage something from that module.

I do not think you have to throw away everything, but i need to better understand your situation - i have still the impression you are mixing up to different worlds. Maybe I screenshot helps of the as-is and to-be target?

daniel_ruiz2
Active Contributor
0 Kudos

Hi Andreas,

While in the Catalogue, the user can switch "Quantity" and "Unit of Measure" - Also, you cannot assume "changing the quantity won't make difference" because there may be conditions or requirements dealing with Quantities in specific: for instance, Scale Prices depends on Quantity not Unit of Measure.

And I'm not mixing anything, just adding functionality that doesn't exist in 'wcem'... all I asked was:

Does anyone have any material about how to re-implement or extend classes (also, the SAP source code) contained in /0SAP/AP_SPC_DOCUMENT_IMPL module inside VMC?

Otherwise, does someone knows how could I make the IPC module call the ABAP stack (with correct back-end users) and only them dispatch the result to VMC?

#2 was kinda answered by Christoph, thou I'm not super convinced I want to walk that path yet.. (at this moment is the only path I could walk tbh) - so I'm still to hear something from SAP or some user that knows a little bit more about #1 since there is no documentation around.

Regards,

D.