Popular Posts

Sunday, June 30, 2013

Helping hands in the world of enterprise middleware - Technical Support

Recently, I got an opportunity to work on a domain which is bit different from my subject matter specialization, software testing and quality assurance. I started to work as a lead of technical support team at WSO2 since November 2012. I thought to put together some key observations I made in technical support career in general and how I position it in terms of my beliefs.

Willingness to help - the most important characteristic of a support engineer

Are you really a helping hand regardless of your profession? How can I understand my willingness in helping others. I would simply list down some questions to evaluate your likelihood to help others.

Do you get frustrated when someone requests your help? If someone asks a question, what is your initial reaction?
In our life, we have seen people who do not even look at the person who requested help. Some people just route the request to some other party without even understanding what kind of help is required.

If you are really a helping hand, you just do not do it because of your professional obligations. You do it simply because you like to help others. You enjoy by observing how your help solves some other's problems.

If you are generously help people in need without hesitation, you possess one of the fundamental characteristics expected from a good technical support engineer.

Listening to others and clear in communication

A good support engineer always listen to others very carefully. She raises many follow-up queries to get the question clarified. She does not attempt to solve the problem blindly without completely understanding the issue at hand. She also communicates very clearly with the clients as well as the other stake holders to help in providing the the best answer.

Expertise in user perspective

Support engineers are clients advocates who should look at the problem through customer point of view. How painful is this issue to my clients? How does it affect their business transactions? When you approach problem from the customer point of view, you first look at what needs to be done before considering how you are going to address the concerns.

Enthusiastic in learning new technologies

To help needy people, you must have a good understanding about the relevant subject matter. You will be clueless if you do not know the problem domain. This is one of the most important attributes especially  in middleware technical support. You will not at least understand a basic question, if you do not step in to learn the technology. The technical support engineer should eager to learn various technologies and find out various solutions to address common problems that can occur.
At WSO2, technology becomes obsolete quite frequently. The technical support engineer must stay up-to-date with the latest features and enhancements introduced to the product platform.

Focus on SLA

Generally, technical support contracts are based on different Service Level Agreements (SLA). There can be various levels of SLA policies. A good support engineer always consider his SLA is now and act fast to find the best resolution for client's issue.

More experiences on technical support, specially related to WSO2 product platform are to be followed....


Friday, June 28, 2013

Invoking WSO2 Carbon admin services with soapUI

The management aspects of WSO2 Carbon platform are primarily achieved through SOAP web services interface known as admin services. All Carbon products ship with a management console (front-end user interface) which communicates with these web services and provides users with various administration capabilities.














In some situations, we need to by-pass the management UI and call the backend web services directly. Specially, in test automation, it is important to minimize the risk of frequent UI changes hence focusing on admin service interactions can be considered as a viable solution. WSO2 test automation framework is built upon this approach which programatically calls the backend web services to manage deployment, configuration and various other tasks.

These backend web services are secured to prevent anonymous invocations. WSO2 Carbon server secures these services through multiple methodologies. For example;

  • HTTP Basic Authentication over SSL
  • WS-Security username token
  • Session based authentication
You can use any SOAP client and communicates with the admin services by authenticating through above security protocols.

In this post, I will take  you through consuming an admin service using soapUI since soapUI is the most user-friendly service testing tool out there to test SOAP or RESTful web services.

We will use HTTP basic auth authentication mechanism out of the auth options described above. If you like to use a different approach such as carbon session based authentication, you may refer to Nandika's blog post.

Pre-requisite:
soapUI 4.5.1 or later
WSO2 Carbon 4.X version (You can use any member product of WSO2 Carbon family)

Step 1


By default, the WSDLs of admin web services are hidden from consumers. Therefore, we need to enable them first to import admin service WSDL into a soapUI project.

Open CARBON_HOME/repository/conf/carbon.xml and set HideAdminServiceWSDLs property to false.

<HideAdminServiceWSDLs>false</HideAdminServiceWSDLs> 


Start WSO2 Carbon server.

Step 2

 

There are large number of admin services which serve many administration and management functionalities such as ServiceAdmin, StatisticsAdmin, ProxyAdmin etc.. However, I will use a simplest admin service, UserAdmin for this example.

Open  https://localhost:9443/services/UserAdmin?wsdl in your browser and check whether it is accessible.

Step 3


Create a SOAP web service project in soapUI using the above WSDL

Step 4


We are going to invoke one of the web services operations exposed through UserAdmin web service. Select listAllUsers operation under UserAdminSoap11Binding interface and click on SOAP request.

Step 5


We are going to submit listAllUsers SOAP request using HTTP basic authentication headers. Therefore, click on Aut tab under the bottom of the request editor and specify the admin  user name and password of carbon server.

















Enter the following values for the required parameters of the SOAP request.

<xsd:filter>*</xsd:filter>
 <xsd:limit>100</xsd:limit>


Step 6

Now, we can submit the request to UserAdmin web service.You will get a SOAP response with all users available in the user store of Carbon server.

Friday, June 21, 2013

How to use SecureVault when WSO2 Carbon servers are started as background processes

SecureVault can be used to encrypt the plain-text passwords specified in various configurations files in WSO2 Carbon products. You can find more information about how to secure plain-text passwords using securevault in this blog written by Asela.

When you use SecureVault to encrypt the passwords as explained there, you are supposed to specify the primary keystore password at the server startup. However, this is not possible when you start the server as a background process.

This post summarizes the complete procedure of securing plain text passwords using secure vault and additional configurations when you start the server as a background process.

Suppose, we need to encrypt the LDAP ConnectionPassword value in CARBON_HOME/repository/conf/user-mgt.xml

  1. Locate cipher-text.properties which can be found at CARBON_HOME/repository/conf/security directory
  2.  Keep a back up of the cipher-text.properties file
  3.  Now, remove all key-value pairs which have there by default in cipher-text.properties file.(In this example, we just need to encrypt ConnectionPassword value)
  4. Add the following line. Make sure to include your plain_text LDAP connection password in [plain_text_ldap_password]

    UserStoreManager.Property.ConnectionPassword=[plain_text_ldap_password]
  5.  Locate ciphertool.sh script which can be found at CARBON_HOME/bin directory
  6.  Run ciphertool.sh as follows
      ciphertool.sh -Dconfigure

    This will prompt "[Please Enter Primary KeyStore Password of Carbon Server : ]" message. Enter "wso2carbon" as the primary keystore password
  7.  If the script execution completed successfully, you will see the following message.
    "Secret Configurations are written to the property file successfully"
  8.  Now, go back and look at the cipher-text.properties file. The plain text LDAP password will be replaced by a cipher value.
  9.  You will also look at CARBON_HOME/repository/conf/user-mgt.xml where we have specified the connection password for LDAP user.
    You will notice that it will be modified by the ciphertool script as follows.
    <Property name="ConnectionPassword" svns:secretAlias="UserStoreManager.Property.ConnectionPassword">password</Property>
  10. Now, you can start the server.
    e.g:- sh wso2server.sh
  11. This will prompt "[Enter KeyStore and Private Key Password :]" at the server startup because we need to decrypt the encrypted passwords to connect to LDAP.
    You can enter "wso2carbon" and the server will be started successfully.

    But you will not be able to provide this password value if you start WSO2 Carbon server as a background process.
    i.e:- ./wso2server.sh start
    In that case, you can follow a simple set of additional steps as explained below
  12. Have a file named "password-tmp" in CARBON_HOME/ directory. Add "wso2carbon" (the primary keystore password) to this file and save
  13. Now, start the server as a background process.
    ./wso2server.sh start
  14. Keystore password will be picked up from password-tmp file. Once the server is started, this fill will automatically be deleted from the file system. Make sure to add this temporary file back whenever you start the sever as a background process.
          NOTE : If you make the name of the password file as "password-persist" instead of "password-tmp" then the fie will not be deleted after reading. Then you don't need to provide the password in subsequent startups.