Access to XmlStore files from within Ws-App java code

Today I needed to have access from within Java Ws-App code to an XML definition located within the XML Store.

Within a Cordys BPM those webservices are available and can be easily drag and dropped into your BPM, but if you need this within your java code it can be easily accomplished by executing a Soap request.

public class XmlStore

{

    final String NS_CASEMNGT_INST = "http://schemas.cordys.com/casemanagement/instanceadministration/1.0";

    public static int getXMLObject(String userDn, String key)

    {

        int retVal = 0;

        int response = 0;

        try

        {

            // Build up the request to send.

            String[] paramNames = { "key" };

            Object[] paramValues = { key };

            SOAPRequestObject sro = new SOAPRequestObject(NS_CASEMNGT_INST , "GetXMLObject", paramNames, 

                        paramValues);

            // Set the proxy user if passed on

            if (StringUtils.isSet(userDn))

            {

                sro.setUser(userDn);

            }

            // Send the actual request.

            response = sro.sendAndWait();

            // Find the response document

            retVal = XPathHelper.selectSingleNode(response, "//xs:old/*", Constants.xmi);

        }

        catch (Exception e)

        {

            throw new CustomException(e, Messages.ERROR_GETTING_FILE_FROM_XML_STORE, key);

        }

        return retVal;

    }

And in the calling function you have than something like this:

Int xmlstoreObject = XMLStore.getXMLObject(BSF.getUser(), "/nl/project/xmlstore/xmlfile.xml");

Don't forget in your calling code to clean-up the NOM element by using the 'Node.delete(node)' function.

Otherwise memory leaks can be easily introduced.

Retrieval of user details of logged-in Cordys user

Retrieval of the user details of the logged-in user can be easily done using the BSF and LDAP build-in utility functions.

Below an example of a Java function which retrieves the ‘Full User Name’ and ‘email’ adres which is shown within the Cordys User Manager. Furthermore, it retrieves the ‘Full Organization Name’ from the Cordys Organisation Manager.

/**
  * This method returns the raadpleger details of the logged-in user.
  *
  * @return  A string array with 3 values:
  *  - value 1: Full Name of the logged-in user
  *  - value 2: Email of the logged-in user
  *  - value 3: Full Name of the organization of the user
 */
 public static String[] getRaadplegerDetails()
 {
    String[] raadplegerDetails = new String[3];

String userDN = BSF.getUser();

    String orgDN = BSF.getOrganization();
   
LDAPDirectory ldir = LDAPDirectory.getDefaultInstance();
        LDAPEntry userLdapEntry = ldir.read(userDN);
        LDAPEntry orgLdapEntry = ldir.read(orgDN);

        // Check if it's an organizational user or an authenticated one.
        LDAPAttribute attr = userLdapEntry.getAttribute("objectclass");
        String[] classes = attr.getStringValueArray();
        boolean found = false;

        for (String className : classes)
        {
            if ("busorganizationaluser".equals(className))

            {

                found = true;

                break;

            }

}

        // Read the entry of the authenticated user if the passed on DN was of an org user.

if (found)

        {

            String authUser = LDAPUtils.getAttrValue(userLdapEntry, "authenticationuser");

            userLdapEntry = ldir.read(authUser);

}

        // Set the Full User Name
        raadplegerDetails[0] = LDAPUtils.getAttrValue(userLdapEntry, "description");
        // Set the Email
        raadplegerDetails[1] = LDAPUtils.getAttrValue(userLdapEntry, "mail");
        // Set the Full Organization Name
        raadplegerDetails[2] = LDAPUtils.getAttrValue(orgLdapEntry, "description");
    }
       return raadplegerDetails;
   }

Show 'Cordys Management Console' graphically on Linux

Problem:
How to open the 'Cordys Management Console' on a Cordys Linux server in a graphical way.

How: 
In order to achieve this we need 2 tools:
- Xming for Windows
- Putty

Actions:
1. Install XMing for windows with default options

2. Configure Putty with X11 forwarding within your session to your server

3. Login and test using the 'xclock' command

4. Start the 'Cordys Management Console' within putty. This is found within the 
Note: we use Cordys CU-17 and there the cmc.sh file is located within the bin directory of the BOP-4 install.

Understanding the SoapAction mystery

For a current project I was asked why a provided WS-I Basic Profile 1.1 compliant webservice wasn't using the SoapAction attribute.
Therefore, I will explain the usage of the SoapAction keyword here.


The SOAPAction header in SOAP 1.1 has given many developers and implementors fits about understanding its purpose. I suggest that this is because of the two very different ways in which SOAP can be used.


Below the statements of the specifications
The SOAP 1.1 specification says this about the HTTP SOAPAction header.
"The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request"


The WS-I Basic Profile says this about the HTTP SOAPAction header

Interoperability testing has demonstrated that requiring the SOAPAction HTTP header field-value to be quoted increases interoperability of implementations. Even though HTTP allows for header field-values to be unquoted, some implementations require that the value be quoted.

The SOAPAction header is purely a hint to processors. All vital information regarding the intent of a message is carried in the envelope.

The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter SOAP request messages in HTTP. The header field value of empty string (”") means that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication of the intent of the message.


So if you’ve got a SOAP message like this one:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">    <SOAP-ENV:Body>       <m:GetLastTradePrice xmlns:m="Some-URI">           <symbol>DIS</symbol>       </m:GetLastTradePrice>    </SOAP-ENV:Body> </SOAP-ENV:Envelope>

Then you see that the intent of this message being sent is the meaning of “GetLastTradePrice”. 

Given this use of SOAP (with the method in the SOAP envelope), it should not be surprising at all that developers are confused, as it appears as though the value of SOAPAction is redundant.

As the SOAPAction is transport specific -an HTTP header field, you should try to avoid it's use when authoring WSDL files for your new services, especially if you plan to use other transports for the same service.
There are only a few usecases where you really need it: it's when you are using overloaded methods (if your language of choice permit it).
The Key to this problem is to understand the relationship between the WSDL and the wire format, and to realize that the name of the wsdl:operation is not necessary present on the wire.

We can imagine a soap envelope like the one below in which no explicit operation is defined.

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">   <env:Body>     <ans1:eid xmlns:ans1="http://ws.fusion.com/">eid</ans1:eid>   </env:Body> </env:Envelope>

From the wire format above, once cannot which operation is called. In order to route such a message, you need extra information - it's the purpose of the SOAPAction header in the list displayed below.

User-Agent: Oracle HTTPClient Version 10h SOAPAction: "urn:lookupEmail" Accept-Encoding: gzip, x-gzip, compress, x-compress Content-type: text/xml; charset=UTF-8 Content-length: 302

The main reason the SOAPAction is used by most Web Services framework is as a performance optimization. It provides a key to lookup the operation where the message should be routed at, without to have to process the SOAP payload (the soap:body).

To sum up:

• use an empty value if you can.
• use it when you are using overloaded methods; the QName of the top-level element of the soap:body can be used to uniquely identify the operation that should process the incoming message

Note that this tips is specific to SOAP 1.1 and will not apply moving forward, as the routing attribute will be factored in the addressing header.

Connect to CARS via external LDAP Client

Problem: How do we connect to Cordys Admin Repository Server (CARS) via an external LDAP client.

How:
Before starting to give a solution for this it is good to know that CARS by default uses one-way SSL for the CARS authentication. This can be changed  of course by adapting the default installation configuration of CARS, but this is not recommended.

Note: changes this can be done by adapting the property: ‘cars.sslmode ‘ withinin the file <instance-name>.properties, which is located within the Cordys install dir.

default CARS settings

Steps to be taken in order to connect to CARS via an external LDAP client

1. First check if you can connect using the Content Manager of the Cordys Management Console into CARS.

2. If step 1 succeeds (login successfull), take over the configuration of the connect screen of the Content Manager and use this information to connect via your external LDAP client (e.g. JXPlorer).

Using this way you are able to connect with your preferred LDAP client to the CARS OpenLDAP implemenation. Another nice LDAP client to use is Apache Directory Studio.

Have fun.

An overview of SSL Authentication

Background on SSL

The industry-standard Secure Sockets Layer (SSL) protocol, which uses signed digital certificates from a certificate authority (CA) for authentication, is used for secure communication.

SSL provides encryption of the data that is exchanged between the applications. Encryption makes data that is transmitted over the network intelligible only to the intended recipient. Signed digital certificates enable two applications connecting in a network to authenticate each other's identity. An application acting as an SSL server presents its credentials in a signed digital certificate to verify to an SSL client that it is the entity it claims to be. An application acting as an SSL server can also be configured to require the application acting as an SSL client to present its credentials in a certificate, thereby completing a two-way exchange of certificates. Signed certificates are issued by a third-party certificate authority for a fee. Some utilities, such as those provided by OpenSSL, can also issue signed certificates.
SSL uses public key encryption technology for authentication. In public key encryption, a public key and a private key are generated for an application. Data encrypted with the public key can only be decrypted using the corresponding private key. Similarly, the data encrypted with the private key can only be decrypted using the corresponding public key. The private key is password-protected in a key database file (keystore) so that only the owner can access the private key to decrypt messages that are encrypted using the corresponding public key.

SSL Authentication

The SSL authentication process uses certificates that are issued by a certificate authority. The same process applies if the certificates are issued by an certificate generation utility or if self-signed certificates are used.

The figure below illustrates the steps that authenticate the identity of an application:

To establish an SSL connection:

1. An application acting as an SSL client contacts an application acting as an SSL server.
2. The SSL server responds by sending the signed certificate stored in its keystore to the SSL client. A CA certificate contains identifying information about the CA that issued the certificate and the application (owner) that presents the certificate, a public key, and the digital signature of the CA.
3. The SSL client uses the corresponding CA certificate stored in its keystore to verify the digital signature on the certificate.
4. In addition to verifying the signature on the certificate, the SSL client requests the SSL server to prove its identity.
5. The SSL server uses its private key to encrypt a message.
6. The SSL server sends the encrypted message to the SSL client.
7. To decrypt the message, the SSL client uses the public key embedded in the signed certificate it received, and thereby verifies the identity of the owner of the certificate.

If the SSL server is set to use two-way SSL authentication (client authentication), it then asks the SSL client to verify and prove its identity, and the same process described above is used to verify the identity of the SSL client to the SSL server.

One-way SSL authentication

One-way SSL authentication enables the application operating as the SSL client to verify the identity of the application operating as the SSL server.
The SSL-client application is not verified by the SSL-server application.

Two-way SSL authentication

In two-way SSL authentication, the SSL client application verifies the identity of the SSL server application, and then the SSL server application verifies the identity of the SSL-client application.

Two-way SSL authentication is also referred to as client authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.

If you are using self-signed certificates, you must create and install the self-signed certificate and private key on the SSL-client and SSL-server applications, then extract the certificate from the keystore of each application and add it to the keystore of the other application.

Cordys: How to update a user interface?

Problem: You want to update a user interface table (e.g. adding of column) which was already generated on top of a database table?


How: This can be easily achieved using the table 'Column Chooser' option
Details:
1) Open the UI screen, and right-click on the user interface table containing all the columns and select “Column Chooser”

 

2) Added database columns will show up within the dialog. The only thing you need to do is select the new column and close the dialog. In case you want to remove columns you can de-select the columns in the same way.

3) You can test the UI (auto publish) using the preview icon () on the top bar.

4) If you want to change the format of a column, you can change this using the ‘Format’ option.

5) There is a bug that Oracle database NUMBER fields are automatically mapped to DOUBLE types within Cordys. Due to this a value of 150 within the database is shown as 150.00 within a Cordys table. This can be easily fixed by changing the “Specific Format” setting of the field to “#”.

6) In order to see the changes of a user interface you have to explicitly clean the cache of your browser. A good tool which is working is dumpcache.exe.