Web Services test harness

The CASL project is the WebSphere Commerce web service test harness, similar to how CaslRest is the test harness for WebSphere Commerce REST services. The CASL project contains the API for making all of the user web service calls.

The test harness API is auto-generated by the CaslBuilder project. The CaslBuilder project produces an exhaustive API of all SOA and SOI web services.
Note: Generally, the web services test harness is used as a last resort. For example, if there is no corresponding method in CaslRestLib-Wc, CaslKeys, or CaslFixtures that can be used to achieve the same results. When the web services framework is used, it is used as part of the test set up or tear down.

CaslKeys: ID Resolver Utility

CaslKeys is a convenience utility, which is used during test setup, that uses CASL, and SQL when necessary. CaslKeys helps find artificial, or internal IDs of an object, based on their natural keys. For example, instead of hardcoding the store ID in a test case, the CaslKeys utility can be used to look up the store ID by store name. By using CaslKeys, your tests are less dependent on data, which can change.

Tooling versus Storefront Keys

There are two types of query classes in CaslKeys,StorefrontKeys and ToolingKeys. StorefrontKeys is a convenience class that takes a store ID in the constructor and retrieves internal IDs that store related objects. ToolingKeys contain methods to retrieve internal IDs of objects that you generally need from the administrators perspective.

An example of the two types of query classes:
@RunWith(GuiceTestRunner.class)
@TestModules({CaslKeysModule.class})
public class TestCaslKeysTooling
{       
       @ClassRule       
       public static final TestRule CLASS_RULE = 
DefaultJUnitLifeCycleRule.getStaticClassRuleInstance();              

       @Rule @Inject       
       public CaslFoundationTestRule fCaslTestRule;              

       @Inject       
       private final Logger f_log;              

       @Inject       
       private CaslKeysFactory f_caslKeysFactory; 
             
       private StorefrontKeys auroraEsiteKeys;    
        
           @Inject       
       public TestCaslKeysTooling() {                  
              auroraEsiteKeys = f_caslKeysFactory.createStorefrontKeys(                          
                            Integer.toString(toolingKeys.getStoreIdByName("AuroraESite")),                          
                            "username", "password");       

      }        

      @Test       
      public void testGetCampaignIDByName() {              
             String uniqueId = auroraEsiteKeys.getCampaignIdByName("campain1");  
                          
             f_log.info("The campaign Id is '" + uniqueId + "'.");       

      }

}

Services API

All of the CASL client facade classes extend the WebSphere Commerce component client libraries AbstractBusinessObjectDocumentFacadeClient class. This common BOD facade client class contains the most primitive methods and factory objects to help create elements of a BOD object. The CASL client facade classes initiate service calls to send a BOD service request.

Each client class contains a class, method, and validation method:
  • An enum class that lists all of the possible access profiles that are associated with the GET services for each nouns web service class.
  • A method for every service verb and noun combination, which takes a list of either the BOD type object as a parameter, for CHANGE/PROCESS, or the XPath key string values for GET services.
  • A validation method for each response type to verify that the contents of a response object from a service call is correct. If it is not correct, it produces an error.

Access profiles

Access profiles pertain only to GET services. Generally, a service XPath indicates what business objects might be returned from a service call and an access profile indicates how much detail about those objects needs to be returned. Access profiles with the prefix IBM_Admin_* are used by WebSphere Commerce Management Center. Access profiles with the prefix IBM_Store_* are used by the WebSphere Commerce store.

Noun builders

The builders for the nouns are automatically generated from the data type interfaces and component factory classes inside of the component library data object classes. These builders use the Component Type Factories from the component client library to instantiate objects at each step. They contain three types of methods. setter methods pass in required attribute values. add methods start building a new object type anywhere there exists an object attribute with a list, and a build method.

Web Services Auto-Generation

Dynamic auto-generation of the web services API is not supported. Any changes, or new additions to the existing commerce web services cannot be accounted for in the test framework by execution of the CaslBuilder generator tool.