One set of instructions to follow would be from the Self-Service Developer’s Guide (Chapter 8 'Customizing the Model Layer…' > Recreating the new Web service client proxy)
Oracle recommends the following steps to replace the vanilla proxy classes with your new proxy classes
a. Locate the vanilla Jar file into which the original proxy classes belong. E.g. the proxies for the Account web services are inside ‘SelfService_ROOT\Model\lib\commoncomp-ws-proxies.jar’
b. Unjar this jar into a temporary directory
c. Replace the vanilla proxy classes with the corresponding new ones
d. Jar the classes in the temporary directory, use the vanilla Jar file name and use this instead of the vanilla jar.
This works, but there are a few issues. Step (a) above is tricky, since there are three vanilla Jar files in the horizontal application – possibly more in the vertical versions. Step (c) wants you to be extra careful and not to miss out any class. Step (d) is not upgrade friendly.
Another Suggestion
An alternate suggestion is to create a Jar file for all the customized proxy classes (or more Jars if you prefer a logical classification or if you hit a technical limit). I will list the steps below, but I have not tried this myself. I would be very happy to get your comments - if it worked or failed and why in the latter case.
a. The vanilla package for the proxy classes for Account web services is:
oracle.apps.ss.base.model.um.proxies.account.<…>.
This path must be used for creating the new proxy classes as well.
So while recreating the web service proxy (Chapter 8 of Dev Guide), at step 10 you would use paths similar to the vanilla package names. You would leave other options to default, ensuring ‘Reuse existing type classes’ is UNCHECKED.
For Account web services the package names are:
Package name: oracle.apps.ss.base.model.um.proxies.account
Root package for types: oracle.apps.ss.base.model.um.proxies.account.types
The paths to use for your specific web service can be identified from import statements in the ‘*UserData.java’ class for the VO. Check out steps 5 and 7 of the post ‘Identifying the Web Service and Java proxy classes behind a Self-Service ADF View Object’.
AccountUserData.java has the following imports
import oracle.apps.ss.base.model.um.proxies.account.types.com.siebel.selfservice.common.allaccountlist.data.ListOfSSAllAccountData; import oracle.apps.ss.base.model.um.proxies.account.types.com.siebel.selfservice.common.allaccountlist.data.SSAllAccountListData; import oracle.apps.ss.base.model.um.proxies.account.types.com.siebel.selfservice.common.allaccountlist.query.ListOfSSAllAccountQuery; import oracle.apps.ss.base.model.um.proxies.account.types.com.siebel.selfservice.common.allaccountlist.query.SSAllAccountListQuery; import oracle.apps.ss.base.model.um.proxies.contact.types.com.siebel.selfservice.common.contact.data.AccountData; import oracle.apps.ss.base.model.um.proxies.contact.types.com.siebel.selfservice.common.contact.data.ListOfSSContactData; import oracle.apps.ss.base.model.um.proxies.contact.types.com.siebel.selfservice.common.contact.query.AccountQuery; import oracle.apps.ss.base.model.um.proxies.contact.types.com.siebel.selfservice.common.contact.query.ContactQuery; import oracle.apps.ss.base.model.um.proxies.contact.types.com.siebel.selfservice.common.contact.query.ListOfAccountQuery; import oracle.apps.ss.base.model.um.proxies.contact.types.com.siebel.selfservice.common.contact.query.ListOfSSContactQuery;
b. One the classes are generated; you would then move these to a temp directory and jar them into ‘ABC_SS_WS_Proxies_1.jar’ or a name you think is more appropriate.
c. Add the new jar to the project libraries.
Right-click the ‘Model’ project and select ‘Properties’
Select ‘Libraries’ in the left tree and click ‘Add Jar/Directory’ to browse and add your new jar file, ABC_SS_WS_Proxies_1.jar, to the project
IMPORTANT: Use the ‘Move Up/Down’ buttons to move the newly added jar to be placed above the vanilla jar files ‘commoncomp-ws-proxies.jar’, ‘eservice-ws-proxies.jar’ and ‘ecommerce-ws-proxies.jar’
d. Compile the ‘Model’ project to ensure there are no errors.
As you can see,
- This approach is cleaner and would require minimal ‘import’ corrections in the related VOImpl and UserData classes.
- Since you are not touching the vanilla Jar files, your work is upgrade friendly


