The workload classification document is a common XML file that classifies inbound HTTP, IIOP, message-driven bean (MDB), and mediation work for the z/OS workload manager.
You must perform the task Classifying z/OS workload when you use the workload classification document. See Sample z/OS workload classification document for an example of a workload classification document.
Indicates the root of the workload classification document. Every workload classification document must begin and end with this element. The schema_version attribute is required. The only supported schema_version is 1.0. The Classification element contains one or more InboundClassification elements. For inbound service integration work, the Classification element can also contain up to two SibClassification elements.
Use the following rules when using the InboundClassification element:
Use the following rules when using the SibClassification element:
The InboundClassification element with the attribute type="internal" defines the section of the document that is applicable to internal work, such as requests that are dispatched in a servant, that originate in the owning controller. An example of this element follows:
<InboundClassification type="internal" schema_version="1.0" default_transaction_class="value1">
If an InboundClassification element with the type="internal" attribute is not specified, internal work is classified using the rules that are specified for IIOP work.
The InboundClassification element with the attribute type="iiop" defines the section of the document that is applicable to IIOP classification. An example of this element follows:
<InboundClassification type="iiop" schema_version="1.0" default_transaction_class="value1">
The name of the application that contains the enterprise beans. It is the display name of the application, which might not be the name of the .ear file that contains all of the artifacts.
The name of the EJB .jar file that contains one or more enterprise beans. There can be multiple EJB .jar files in an .ear file.
The name of the EJB that is contained in a module (or EJB .jar file). There can be one or more enterprise beans contained in a .jar file.
The name of a remote method on an EJB.
Classify IIOP work in various applications at any of these levels by using the iiop_classification_info element.
<iiop_classification_info transaction_class="value1" [application_name="value2"] [module_name="value3"] [component_name="value4"] [method_name="value5"] [description="value6"] >With the iiop_classification_info element, you can build filters based on the application, module, component, and method names to assign TCLASS values to inbound requests. Use the following rules when using the iiop_classification_info element:
You can use any combination of these attributes to make a classification filter. But you should only use the granularity that is required. For example, if there is only one application on the application server, the classification rules do not need to specify the application_name attribute.
<iiop_classification_info transaction_class="FAST" application_name="MyAPP1" component_name="EJB1" /> <iiop_classification_info transaction_class="SLOW" application_name="MyAPP1" component_name="EJB2" />The following filter also classifies requests on EJB1 and EJB2 in the MyAPP1 application, but also classifies requests on any other EJB in the application:
<iiop_classification_info transaction_class="MEDIUM" application_name="MyAPP1"> <iiop_classification_info transaction_class="FAST" component_name="EJB1" /> <iiop_classification_info transaction_class="SLOW" component_name="EJB2" /> </iiop_classification_info>
<iiop_classification_info transaction_class="FAST" application_name="MyAPP1"> <iiop_classification_info transaction_class="SLOW" application_name="MyAPP2" /> </iiop_classification_info>In this example, EJB Requests in MyAPP2 would never be assigned to transaction class "SLOW" because the higher level filter only allows IIOP requests for application_name="MyAPP1" to be passed through to the lower level filter.
<iiop_classification_info transaction_class="FAST" application_name="MyAPP" /> <iiop_classification_info transaction_class="SLOW" component_name="*" /> <iiop_classification_info transaction_class="MEDIUM" component_name="MySSB" /> </iiop_classification_info>In the preceding example, all the IIOP requests that are processed by enterprise beans in the MyAPP application are assigned a TCLASS value of SLOW. This is true for any requests to the MySSB enterprise as well. Even though MySSB is assigned a transaction class, the filter is not applied because the first filter was applied and was assigned a TCLASS value of SLOW. The remaining list of filters at the same level is ignored.
The InboundClassification element with the attribute type="http" defines the section of the document that is applicable to HTTP classification. An example of this element follows:
<InboundClassification type="http" schema_version="1.0" default_transaction_class="value1">HTTP work can be classified based on the following J2EE artifacts:
Specifies the host name in the HTTP header to which the inbound request is being sent.
Specifies the port on which the HTTP catcher is listening.
The string that identifies the Web application.
<http_classification_info transaction_class="value1" [host="value2"] [port="value3"] [uri="value4"] [description="value5"] >With the http_classification_info element, you can build filters based on the host, port, and URI to assign TCLASS values to inbound requests. Use the following rules when you use the http_classification_info element:
<http_classification_info transaction_class="FAST" host="MyVHost1.com" uri="/MyWebApp1/*" /> <http_classification_info transaction_class="SLOW" host="MyVHost2.com" uri="/MyWebApp2/*" />
<http_classification_info transaction_class="MEDIUM" host="MyVHost1.com"> <http_classification_info transaction_class="FAST" uri="/MyWebApp1/*" /> <http_classification_info transaction_class="SLOW" uri="/MyWebApp2/*" /> </http_classification_info>Both filters classify requests to Web applications that are identified by context roots /MyWebApp1 and /MyWebApp2 in the application server that is hosting web applications for virtual host MyVHost1.com. However, the second filter also classifies requests on any other context root in the application server.
<http_classification_info transaction_class="FAST" uri="/MyWebApp1/*"> <http_classification_info transaction_class="SLOW" uri="/MyWebApp2"> </http_classification_info> </http_classification_info>This example would never result in Web applications with a context root of /MyWebApp2 being assigned to the transaction class SLOW. The high level filter only allows HTTP requests with a context root of /MyWebApp1/* to be passed to a lower level filter.
<http_classification_info transaction_class="FAST" host="MyVHost.com" /> <http_classification_info transaction_class="SLOW" uri="*" /> <http_classification_info transaction_class="MEDIUM" uri="/MyWebAppX/*" /> </http_classification_info>In this example, HTTP requests processed by the application server by the virtual host "MyVHost.com" are assigned a TCLASS value of SLOW. Even requests to the Web application with context root /MyWebAppX are assigned a TCLASS value of SLOW because the filter was not applied. The first filter that matches is used for the TCLASS assignment, and the remainder of the filters at the same level is ignored.
<InboundClassification type="mdb" schema_version="1.0" default_transaction_class="qrs">
<endpoint type="messagelistenerport" name="IPVListenerPort" defaultclassification="MDBX" description="ABC">Use the following rules when defining your endpoint elements:
<classificationentry selector="Location='East'" classification="MDB2" description="XYZ" />Use the selector attribute of the classificationentry element to assign a transaction class to a message-driven bean that has a selector clause in its deployment descriptor. Use the following rules when defining your classificationentry elements:
<SibClassification type="jmsra" schema_version="1.0" default_transaction_class="a">
<sib_classification_info selector="'East'" transaction_class="sibb" selector="user.Location='East'" bus="bigrred" destination="abusqueue" description="Some words" />
Each sib_classification_info element can contain one or more of these properties as needed to classify the work for a message. A sib_classification_info element cannot contain more than one instance of each property.
<sib_classification_info bus="MyBus" transaction_class="a" /> <sib_classification_info destination="MyDest" transaction_class="b" />A message that arrives at destination MyDest from the service integration bus MyBus is assigned the classification "a". A message that arrives at MyDest from another bus is assigned the classification "b".
If a message does not match any sib_classification_info element in an enclosing SibClassification element, the message is assigned the default classification from the SibClassification element.
If a message does not match any sib_classification_info element in any SibClassification element, or if no SibClassification elements are defined, all work receives a built-in default classification with the value "SIBUS". You must perform z/OS Workload Manager actions that are required to use the TCLASS value "SIBUS", as described in Classifying z/OS workload.
<SibClassification type="destinationmediation" schema_version="1.0" default_transaction_class="b">
<sib_classification_info transaction_class="e" selector="user.Location='East'" destination="themoon" discriminator="sides/dark" description="n" />
For more information, see Working with the message properties.
Each sib_classification_info element can contain one or more of these properties as needed to classify the work for a message. A sib_classification_info element cannot contain more than one instance of each property.
<sib_classification_info transaction_class="e" destination="themoon" description="n" /> <sib_classification_info transaction_class="f" description="n" />A message that arrives at the mediated destination themoon is assigned the classification "e". A message that arrives at another mediated destination is assigned the classification "f".
If a message does not match any sib_classification_info element in an enclosing SibClassification element, the message is assigned the default classification from the SibClassification element.
If a message does not match any sib_classification_info element in any SibClassification element, or if no SibClassification elements are defined, all work receives a built-in default classification with the value "SIBUS". You must perform z/OS Workload Manager actions that are required to use the TCLASS value "SIBUS", as described in Classifying z/OS workload.