cgriffin 120000CMTR Visits (3136)
With MDM Workbench 9.0.x, you may find that web service deployment classes are not generated for data extensions. This causes runtime errors when invoking web services affected by data extensions, typically a class not found error referring to a class name with suffix _Ser, _Deser, or _Helper. Classes with these names should be generated when you run Prepare for Deployment on WSEJB projects. If these classes are not generated, the web service won't work.
To resolve this error, right-click on PartyWSEJB (you need to repeat this for each affected WSEJB project), select Properties. Select Project Facets. Check the facet: WebSphere EJB (Extended). Save changes, and run Prepare for Deployment on the WSEJB project.
I have added this information to the MDM Workbench FAQ. Thanks to Bark Bakker, for finding the workaround.
If you know of a good solution to a common problem, then please do add it to the MDM Workbench FAQ so that other users can benefit. And if you are having problems, please look at the MDM Workbench FAQ before posting to the MDM Workbench newsgroup, as you may find an answer there.
ELizBeth 270005BAKK Visits (4388)
You must have faced quite a good amount of code generation issues if you are working on MDM Server v8 or v8.5. One of the main problems that I have faced was whenever we do not have a hold on the OOTB code generation technique. Say if you need to have OOTB TCRM
Errors logged during code generation
Errors occurred during execution
Error executing tag handler: java
Another problem which we face is, MDM does not support the Transient Object code generation in v8 or 8.5 Hence we have land up with no other option other than to create an Entity, its corresponding classes and will not be persisted. It would be used as a wrapper object. Therefore, your project may have unnecessary files which you may not use in MDM framework.
By this approach it helps the developer to have a strong hold on how your service description should be by writing your own WSDL and generating the java code based on the definition in the WSDL. Definitely, this approach would be challenging as it will not be as simple as clicking the Generate Code in the MDM Model Editor
RAD : 220.127.116.11
MDM : MDM Server v 8.5
WAS : v6.1
Creating Top-Down Web Service
Web services can be created using two methods: top-down development and bottom-up development. Top-down Web services development involves creating a Web service from a WSDL file.
When creating a Web service using a top-down approach, first you design the implementation of the Web service by creating a WSDL file. You can do this using the WSDL Editor. You can then use the Web services wizard to create the Web service and skeleton Java™ classes to which you can add the required code.
Although bottom-up Web service development may be faster and easier, the top-down approach is the recommended way of creating a Web service. By creating the WSDL file first you will ultimately have more control over the Web service, and can eliminate interoperability issues that may arise when creating a Web service using the bottom-up method.
The tools that help to generate the web service artifacts are WSDL2JAVA.bat and JAVA2WSDL.bat.
WSDL2JAVA generates the web service skeletons and the deployment descriptor templates against a WSDL. This is used for the top down approach
JAVA2WSDL generates WSDL from the Java class. This is used for bottom up approach.
This document helps you to create a top to down EJB implementation of Web Service for MDM services. It is quite simple to develop a web service with the help of Web Service editor that is available with the RAD.
By the end of this document, you will be able to create an ejb web service implementation from WSDL to invoke MDM services.
Note: We need to have manual effort to bring up the web service project structure in sync with the classes and the class names that gets generated with the help of MDM model editor.
RAD Preference Settings
Prior to developing the Web Service, you need to set certain Preferences in RAD.
1. Windows > Preferences > Web Services > Resource Management
Note: It is a good practice to select this option when you use utility JAR files or third party libraries, in order to avoid these loadable Java Classes that have to be regenerated.
Below are the steps which explain how to create a top down EJB web service implementation:-
Click Next > Generates the Web Service skeleton from the WSDL and publishes the project to the server
Note:- Start the server before generating the web service
i. Move the SearchBindingImpl to Proj
ii. Rename the below files:-
SearchBindingImpl -> SearchServiceBean
iii. ejb-jar.xml ->
a) Modify the mapping of
ix. If you have defined wrapper object in WSDL to hold any OOTB objects, make sure you create the BObj, Converter and Constructor for the same.
As of version 10.1, MDM is secured by default. This means that using the Web Service Explorer to test your web service will not be possible. Whilst there are many web service testing tools out there like SOAPUI, there is one that is included within the MDM Workbench that you can use, the Generic Service Client. The following steps detail how to invoke the required MDM web service :
This will then open the following editor :
The responses are saved and can be rerun, but if you want more functionality you'll probably need to look at Rational Performance Tester
MDM AE pMDM with RESTful web services
Previously, interactions with MDM Operational server were possible with EJB/RMI, JMS, JAX-WS and JAX-
Possible payloads that are accepted are application/xml and application/json. JSON support was added in v11.4 FP1.
It is important to note that all REST interaction are using one RESTful service “MDMWSRESTful”, PUT method type only and accessed via URI http
The same xml request/response payload used for EJB/RMI is used for REST interactions.
For the full list of capabilities and supported request headers consult the following documentation link:
Interacting with MDMRESTful service
Here’s a sample client leveraging Apache Wink demonstrating an MDM RESTful call:
The above code will submitting an MDM xml payload and expecting back an xml response.
This is determined by the ‘Content-type’ and ‘Accept’ http header properties.
Here’s a look at a getParty xml payload and response:
The same request/response as JSON, using application/json, as both content-type and accept:
The default MDM JSON model is actually based on the core XML schema model (MDMCommon.xsd and MDMDomains.xsd). Internally, MDM will validate the JSON using these schemas.
We use a “Mapped notation” api to build the JSON. A couple things to note about this implementation:
Don’t want to write any code to test your MDM services?
Choose “PUT” as the HTTP method
curl --user "mdmadmin:mdmadmin" -X PUT