White Papers
Abstract
Part 2 of this 3-part article series takes the next step of taking the SLA control file used in Part 1 and replacing it with a proper business service registry solution. The article will show how to use the WSRR Governance Enablement Profile (GEP) service model to capture and publish the same (and more) service metadata as available in the SLA control file.
Content
The service level agreement (SLA) policy enforcement and service governance has become a critical component of proper SOA adoption and service management practices. In order to properly implement such capability in enterprise networks, the service proxies and gateways must be aware of business service endpoints and their consumer SLAs. This metadata may exist in the enterprise in varied forms, such as documents, spreadsheets, databases, repositories, and so on. In Part 1 of this series, we discussed how a self-contained solution (for example, no external dependencies) using DataPower Application appliance can enforce business service SLA policies and help improve service governance in the enterprise. That initial article made use of a local "SLA Control File" pattern, which uses an XML file to provided the source of information for details about services, consumers, and their SLA policies. This article, Part 2 in the series, takes the next step of taking the SLA Control File used in the first article and replacing it with a proper business service registry solution. We use the WebSphere Part 3 of the series documents the WSRR solution's DataPower configuration artifacts and provides step-by-step testing and validation instructions. Part 2 and Part 3 of this article series demonstrate the various types of business service policies that you can manage by using this solution's framework and how to easily associate these policies to service consumers and service providers for individual enforcement. It details the implementation of a simplified WSRR GEP service model focused on services, policy, SLA, and SLD registration. The SOA architecture pattern roles applied in this article are DataPower as the Policy Enforcement Point (PEP) and WSRR as the Policy Administration Point (PAP). This SOA pattern instantiation demonstrates the ability to manage different versions of a service, associated SLA policies, endpoint routing, and any data mediation (as needed). You can apply this solution pattern to any type of service that the DataPower appliance can proxy and protect: XML, REST, or Web Services (SOAP). We describe how to configure this solution by using the most widely used DataPower service gateways: Multi-Protocol Gateway (MPGW) and Web-Service Proxy (WS-Proxy). We also describe in detail how to leverage key SOA features, such as service re-use, governance, and visibility in WSRR. The pattern implementation described in this article requires DataPower v4.0.2 (or higher) and WSRR v7.5 (or higher). Figure 1 presents a high-level diagram of interaction between different components of the solution pattern. Notice, when compared to the Part 1 article's local XML control file, that the service and policy metadata is consumed from a location external to DataPower (for example, WSRR). This provides the benefits of enabling distributed governance of service definitions and policies associated. This is a significant improvement from the first article, where local files have to be manually managed by custom scripts, and thus, likely suffer from spotty service and policy coherence. This gets worse as the solution is scaled out. This section discusses the proposed solution pattern that uses a WSRR service model to describe services and their associated SLA and SLD policy details. A WSRR service model allows consumers and providers to be managed by using governance capabilities and also exposes these services and associated SLAs, SLDs, and endpoints as visible resources to enable "reuse". The following simplified model is used by this article to allow basic governance capabilities. You can extend this model to fully encompass all the capabilities that WSRR provides, thus enabling more advanced features such as policy management and authoring, full governance enablement, search and reuse, and Enterprise Service Bus (ESB) integration. The previous article made use of the SLA-check stylesheet and its configuration XML file, which both reside locally on the appliance. In this article, we'll set up the objects in WSRR v7.5 (all instructions also apply to a WSRR v8.0 installation), which the DataPower appliance will query and pull the required information from the specified WSRR server instance. The next article in this series will explain how to configure DataPower and show examples. Figure 2 shows the WSRR service models that are created and used in this article. The objects and their additional properties are described later in the article. The simplified model uses the following key "governance" aspects: This section demonstrates the integration between DataPower and WSRR to enforce SLA and SLD for the following gateways: For each type of gateway, a presentation of the WSRR components as well as the DataPower configuration are explained. XML and REST gateways are configured on DataPower using multi-protocol gateways. This type of proxy is used in DataPower to protect Web services that comply with W3C specifications (such as WSDL, SOAP, and WS-Policy). The proxy configuration will assume that the Web service expects messages to be SOAP (such as XML) and use HTTP(S) protocols, as well as provide a WSDL for defining the service interface. When dealing with SLA and SLD enforcement for SOAP-based services, the following WSRR components must be created, as shown in Figure 3, where two service versions of the same service are created. Every service version has its own SLD with only one online endpoint at a time. You must add the dp_slmPolicyName property at the SLD and SLA level to provide information about the SLD SLM policy and the SLA SLM policy that has to be enforced on the DataPower device at runtime. These SLM policies need to be configured on the DataPower appliance with exactly the same names of those used in WSRR. The validation of SOAP messages (on both request and response side) is performed using the WSDL files retrieved by DataPower, once the subscription between DataPower and WSRR is established. The DataPower appliance integrates to WSRR using the "WSRR subscription" configuration. DataPower supports several different types of subscriptions to WSRR (one example is shown in Figure 4). DataPower Web Service proxies can consume and configure themselves with WSDLs and policies that reside in a WSRR server through the use of these WSRR subscription objects. DataPower WSRR subscriptions provide a mechanism in which a WS-Proxy can be configured by subscribing to one or more WSDLs stored on the WSRR server. The DataPower WSRR subscription may subscribe and consume one or more WSDLs (multiple WSDLs are supported via the concept or a saved search in WSRR). In this article, we take advantage of the existing interoperability between DataPower and WSRR and expand it to include the retrieval of SLA and SLD policies via custom named queries. We'll create a saved search subscription (Figure 4), which results in a set of WSDLs from WSRR that are configured into a Web Service proxy. Then, we'll create a processing rule at the top level of proxy, as shown in Figure 5, which contains actions that communicate with the WSRR server to retrieve policy directives for specific consumer and service. The fetched policy and service metadata from WSRR are then stored into known context variables. In this article, the values stored are the names of the SLM policies applied to SLA and SLDs, as well as any transformations and XSDs or WSDLs for schema validation. The provided DataPower configuration also contains a Multi-Protocol Gateway (MPGW), which enforces the SLD processing policy, shown in Figure 6, serially after the WS-Proxy enforcement of the SLA processing policy. DataPower firmware 4.0.2 (and previous versions) require this two-gateway implementation as only one SLM action is allowed per processing rule. Note: Starting with DataPower firmware 5.0.0 (and later), this limitation no longer exists. Therefore, a WS-Proxy configuration can enforce both SLM actions (SLA and SLD policies) serially shown in the same WS-Proxy processing rule. The WS-Proxy forwards the request to the MPGW, which enforces the SLD policy. After it is done processing, the MGPW then routes the request to the desired remote endpoint for processing by the Web service. In order to deal with service versioning for SOAP-based services, we assume that "service A" (Service_Endpoint_A) is now offline. We continue to manage this service in WSRR, but the implementation of "Service A" does not exist anymore. We want to demonstrate how to deal with SOAP-based services versioning in DataPower and WSRR for this particular use case. From a WSRR perspective, the service endpoint Service_Endpoint_A is set as offline. Some new properties are set at the SLD level to manage the data mediation on both request and response processing rules in DataPower, as shown in Figure 7. Using this set of information, a DataPower Web-Service proxy is able to: Moreover, you can enforce the SLA SLM policy and the SLD SLM policy as desired. Figure 8 shows the two DataPower request processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower. We have added markers to each action in Figure 8, 1 through 8, in order to more easily reference them in the article. SLA and SLD enforcements can be completed with some classical security controls provided in DataPower like an AAA policy. The parameters are: The WSRR consumer and SLA modeling make use of a Consumer ID (a simple string property that identifies the business application consuming a service) and Context ID (a simple string property that identifies the SLA object associated with consumer and provider pair). The DataPower solution uses these two IDs to query WSRR for appropriate SLA and SLD policy metadata to use during enforcement actions. In the article, consumer and context identifiers are transmitted in the HTTP headers using, respectively, X-CONSUMERID and X-CONTEXTID parameters. This initial stylesheet parses the incoming requests and extracts a Consumer ID and SLA Context ID from the message. I It then uses those two values in a series of calls to the WSRR NamedQueries. The stylesheet then gathers and sets local context variables, which are used in subsequent enforcement actions. The stylesheet also creates and returns an action output context <result> XML nodeset with some of the queried data. Here is an example of action's output context nodeset: The validate action details are displayed in Figure 11. The schema validation method is based on the WSDL URL. The SLM Action used by the service level agreement is shown in Figure 14. Note the SLM Policy name is read from the DataPower context variable "var://context/wsxml/sla". The actual DataPower SLM policy configuration is expected to already exist on the appliance and be operational (up state) as shown later in this article. This means that SLM policy options are designed up-front and deployed as part of the gateway configuration lifecycle process. Figure 18 shows the two DataPower response processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower. The processing is similar with what we have seen on the request processing side. In the first step, the Xform action is responsible for retrieving information from WSRR, using specific named queries. Validation of the SOAP response is performed in a second step, and then comes the data mediation. These three actions are processed on the response processing rule of the Multi-Protocol Gateway used to enforce SLD through an SLM policy. The SOAP response, with a format required by the consumer (Consumer_A), is then validated and sent back to the consumer application. The last Xform (on the right side) corresponds to a custom log action. Note: On the SOAP-based service use case, the schema validation method of the validate actions of the SLD gateway is based on the WSDL URL. On the SLD gateway, the validate actions are configured on the response processing rule. Figure 19 shows an example of such a validate action. You can set the request and response types of the SLD gateway to "XML" when dealing with SOAP and XML based services, as shown in Figure 20. This gateway type refers to a DataPower Multi-Protocol Gateway (MPGW) configured to assume that service messages will be in the XML format. It is basically a MPGW with configuration settings that are enabled to process XML (validate, parse, and create) and enforce XML protections (schema validations, crypto standards, limits, threats, and so on). This allows a gateway configuration to be optimized to use many of DataPower's XML features. When dealing with SLA and SLD enforcement for XML-based services, you must create the following WSRR components, as shown in Figure 21, where two service versions of the same service are created. Consumer_A consumes Version A of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device. Consumer_B consumes Version B of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device. Every service version has its own SLD with only one online endpoint at a time. You must add a dp_slmPolicyName property at the SLD and SLA level to provide information about the SLD SLM policy and SLA SLM policy that has to be enforced on the DataPower device at run-time. These SLM policies need to be configured on the DataPower appliance with exactly the same names of those used in WSRR. The validation of XML messages (on both request and response side) is performed using schema files (XSD) retrieved by DataPower using a specific named query (GetBackEndSourceDoument). The result of a named query invocation can be cached to improve performance and reduce the number of REST calls to WSRR. When dealing with XML based services, the DataPower appliance integrates to WSRR using custom named queries. The type of DataPower service used to implement the XML gateway for SLA enforcement is a Multi-Protocol Gateway. The configuration of this Multi-Protocol Gateway used to expose XML-based services is the same as the one used for SOAP-based services. The only difference is the schema validation method that is based on the schema URL for XML-based services (instead of the WSDL URL for SOAP-based services). The SLD gateway is also the same as the one used for SOAP-based services, but again, the schema validation method for all the validate actions of the processing policy must be based on the schema URL. To deal with service versioning for XML-based services, we assume that "Service A" (Service_Endpoint_A) is now offline. We continue to manage this service in WSRR, but the implementation of "Service A" does not exist anymore. We want to demonstrate how to deal with XML-based services versioning in DataPower and WSRR for this particular use case. From a WSRR perspective, the service endpoint Service_Endpoint_A is set as offline. The schema of Service A is always used to validate XML messages for both request and response processing. Thus, a dedicated relationship is used to reference this schema through the use of the dp_xsd_frontEnd property at the service version level. Some new properties are set at the SLD level to manage the data mediation on both the request and response processing rules in DataPower, as shown in Figure 23. Using this set of information, a DataPower Multi-Protocol Gateway is able to: On the response processing, the following steps are executed: Moreover, the SLA SLM policy and the SLD SLM policy can be enforced as desired. Figure 24 shows the two DataPower request processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower. Figure 25 shows the two DataPower response processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower. The processing is similar with what we have seen on the request processing side. The Xform action is responsible for retrieving information from WSRR using specific named queries. Validation of the XML response is performed in a second step, and then comes the data mediation. These three actions are processed on the response processing rule of the Multi-Protocol Gateway, which is used to enforce SLD through an SLM policy. The XML response, with a format required by the consumer (Consumer_A), is then validated and sent back to the consumer application. The last Xform (on the right side) corresponds to a custom log action. Important: The XML-based service use case, the schema validation method of the validate actions of the SLD gateway, is based on the schema URL. On the SLD gateway, the validate actions are configured on the response processing rule. An example of such a validate action is shown in Figure 26. This gateway type refers to a DataPower Multi-Protocol Gateway (MPGW) configured to assume that service messages will be in non-XML format. It is basically a MPGW with configuration settings enabled to process non-XML payloads. This allows support for services that expect JSON or HTML, for example. Therefore, no validation or parsing of payload is performed. This is in contrast to the XML Gateway where XML protections can be enforced. When dealing with SLA and SLD enforcement for the REST-based services, you must create the following WSRR components, as shown in Figure 27, where two service versions of the same service are created. Consumer_A consumes Version A of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device. Consumer_B consumes Version B of the service with specific SLA and SLD SLM policies set in WSRR and enforced on the DataPower device. Every service version has its own SLD with only one online endpoint at a time. A dp_slmPolicyName property must be added at the SLD and SLA level to provide information about the SLD SLM policy and the SLA SLM policy that have to be enforced on the DataPower device at run-time. No schema file is mentioned for the REST use case, as a REST service invocation can be based on an HTTP GET request. It cannot be schema validated. If control of the query parameters must be performed, then use a transformation on the request side to enforce it. When dealing with REST-based services, the DataPower appliance integrates to WSRR using custom named queries. The type of DataPower service used to implement the REST gateway for SLA enforcement is a Multi-Protocol Gateway. The configuration of the processing policy used to deal with REST-based services is the same as the one used for SOAP and XML based services. Neither schema nor WSDL validation is performed on the request and response side for REST-based services. Only routing, SLA and SLD enforcements, as well as transformation can be executed in this case. The SLD gateway is also the same as the one used for SOAP or XML based services, but again, the validate actions of the processing policy are not executed. Figure 28 presents the request and response types for both SLA (mpg_rest_sla_proxy) and SLD (mpg_sld) enforcement gateways. In order to deal with service versioning for REST-based services, we assume that "Service A" (Service_Endpoint_A) is now offline. We continue to manage this service in WSRR, but the implementation of "Service A" does not exist anymore. We want to demonstrate how to deal with REST-based services versioning in DataPower and WSRR for this particular use case. From a WSRR perspective, the service endpoint Service_Endpoint_A is set as offline. Some new properties are set at the SLD level to manage the data mediation on both the request and response processing rules in DataPower, as shown in Figure 29. Using this set of information, a DataPower Multi-Protocol gateway for REST services is able to: On the response processing, data mediation of the response using the dp_xformName_Response property is executed. Figure 30 shows the two DataPower request processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower. Figure 31 shows the two DataPower response processing rules as one flow. The colored lines indicate where each property from the WSRR objects is used in DataPower. The processing is similar with what we have seen on the request processing side to handle REST services. An Xform action is responsible for retrieving information from WSRR using specific named queries. Then comes the data mediation that you can use to transform or control the REST service response. These two actions are processed on the response processing rule of the Multi-Protocol Gateway used to enforce the SLD through an SLM policy. The REST service response, with a format required by the consumer (Consumer_A), is sent back to the consumer application. The last Xform (on the right side) corresponds to a custom log action. This article uses some user-defined WSRR named queries to make the DataPower appliance stylesheet logic simpler, as well as allowing easy configuration of the WSRR configuration profile. These named queries are provided in the Download section of this article as WSRR XML configuration objects. To load these into WSRR, switch to the "Configuration" perspective in the Web GUI and then select Active Profile >Named Queries. Select Load Named Query Configuration and upload each of the attached Named Query configuration XML files, specifying the "name" of the query as the same as the XML file name (without the .XML extension, see Figure 32). The provided named queries are: This performs a check for an "Active" SLA contract of the required level contextId between the consuming Application (consumerId) and the provided service, which must have an "Online" available endpoint. The DataPower configuration uses a Consumer ID of "OrderServiceConsumer001" and a Context ID of "OrderServiceGold". A sample query looks like the following: The response resembles Figure 33, where the name of the SLM policy for the given SLA is highlighted. This is a query to return the provided service SLD to help the stylesheets navigate to the associated modeled objects. Using the same Consumer ID and Context ID, the request is: The response resembles Figure 34. The transforms from one version to another are highlighted, along with the name of the SLM Policy for the SLD. This is a query to return the optional frontend XSD document for scenarios where a message transformation is required in the appliance before routing to the provided backend endpoint. In our example, a frontend XSD is not used, so the results from the query is empty and the bsrURI used is obtained from the previous GetServiceSLD named query. This is a query to return the providing service WSDL or the XSD document representing the backend service. Using the same consumer and context ID, the query is: The response shown in Figure 35 contains the bsrURI of the WSDL or XSD to use in the validation step. This queries the "Online" backend endpoint for the given "Active" SLA contract and the consuming application. The query results in a response similar to Figure 36. A typical scenario in an SOA organization, which manages multiple online versions of service providers, is exposing multiple versions (such as v1.1, v1.2) of the same service, but maintaining those using only a single backend service version ( v1.2). This then maintains a back-level external service version (v1.1) for those consuming application clients that have not yet moved to the latest version specification, but enables the service provider to only provide and maintain the latest (v1.2) backend endpoints. The following sections describe how to configure both the DataPower appliance and WSRR to manage this scenario. The following sections describe the WSRR Web GUI interactions to create the example of simplified WSRR artifacts shown in the model diagram (Figure 2). Using an administrator role, log into the WSRR Web GUI. Navigate to Business Objects > Service Version and create a new service version for the providing service (Figure 37). Navigate to Business Objects > Service Level Definition and create the providing service contract (Figure 38). From the OrderService service version detail, select Edit Relationships so that the OrderService-SLD can be applied to the providing service (Figure 39). Now load the example OrderService.wsdl service definition along with its schema, OrderServiceSchema.xsd. Select Service Documents > WSDL/XSD Documents and then Load Documents (Figure 40). Now add the service interface just created from loading the WSDL service definition as the "Service Interface" for the OrderService-SLD (Figure 41). This defines the interface for the providing service contract. Now add the service port just created from loading the WSDL service definition as the "Bound Web Service Port" for the OrderService-SLD (Figure 42). This defines the bound port for the providing service contract. The OrderService-SLD can now be governed and transitioned to the "SLD Subscribable" state. Navigate to the OrderService-SLD detail panel and select the Governance tab. Then using the Transition button, transition its state to SLD Subscribable (Figure 43). This providing service contract is now available for consumers. Now switch to create the consuming application version called "OrderApplication" in this example. Navigate to Business Objects > Application Version, and create a new application version, ensuring to set both the version and consumer identifier properties (Figure 44). You can now create the consumer to providing service version service level agreement contract. Navigate to Business Objects > Service Level Agreement and create a new service level agreement called "OrderApplication-OrderService-SLA" with a "Context Identifier" attribute of "OrderServiceGold" (Figure 45). The context identifier attribute is a unique key identifying this contract with the providing service. The service level agreement now needs to bind to the agreed OrderService-SLD. Edit the relationships of the OrderApplication-OrderService-SLA to add the OrderService-SLD as the agreed endpoint (Figure 46). The service level agreement can now be transitioned to the "SLA Active" state, indicating this contract between the consumer and providing service version is available. Navigate to the OrderApplication-OrderService-SLA detail panel and the Governance tab, and transition it to the SLA Active state (Figure 47). Now relate the SLA to the actual consuming Application Version (OrderApplication) by editing the relationships of the OrderApplication and selecting the OrderApplication-OrderService-SLA object for the target of the "Consumes" service level agreement (Figure 48). The OrderService endpoint created when the WSDL definition was loaded now needs to be classified to an environment before it is made available and set online. Navigate to Business Objects > SOAP Service Endpoint and select the orderService endpoint. Then from its detail panel, select the Edit Classifications link, add the classification Governance Profile Taxonomy > Environment > Production, and select OK (Figure 49). The orderService endpoint can now be set to the "online" state, making it available for a providing service. Navigate to the orderService SOAP service endpoint and the Governance tab, and transition it to the Online state (Figure 50). The orderService endpoint can now be made available to the OrderService-SLD. Navigate to Business Objects > Service Level Definition for OrderService-SLD and select Edit Relationships, then select Add Service Endpoint for Available Endpoints and add the orderService endpoint (Figure 51). The complete set of the WSRR artifacts for the SOAP WebService OrderApplication consuming from the OrderService version example are now created and available for integration with the DataPower appliance. You can now extend the OrderService-SLD to add additional types of endpoints. This section demonstrates the addition of an XML-based WebService endpoint. Navigate to the Business Objects > Service Endpoint and create a new service endpoint called Add the XML schema document that describes the XML endpoint interface as the sourceDocument relationship of the service endpoint (Figure 53). In the same way as the SOAP service endpoint, the XML service endpoint now needs to be classified with a "production" environment, governing and transitioning to the "online" state, and then adding as an "available endpoint" for the OrderService-SLD (Figure 54). The complete set of WSRR artifacts for the XML-based WebService example is now created and available for integration with the DataPower appliance. You can extend the OrderService-SLD to add the final example type of the endpoint for REST. This section demonstrates the addition of the REST service endpoint. Navigate to the Business Objects > Service Endpoint and create a new service endpoint called In the same way as the XML service endpoint, the REST service endpoint now needs to be classified with a "Production" environment, governing and transitioning to the "Online" state, and then adding as an "Available Endpoint" for the OrderService-SLD (Figure 56). The complete set of WSRR artifacts for the REST-based WebService example is now created and available for integration with the DataPower appliance. This second article in this SLA enforcement series introduced a solution pattern that provides an prescriptive approach to adopt proper SOA principles of service governance and policy-based enforcement based on DataPower and WSRR products. The solution's implementation leverages WSRR's strengths as an enterprise SOA Policy Administration Point (PAP), which is a natural evolution of the initial SLA Control File approach presented in Part 1. It is difficult to fully adopt and meet SOA goals without proper centralized service and policy administration. Additionally, DataPower v5.0 (and later) provides integration with WSRR v7.5 (and later) that reduces the level of effort required to govern and deploy Web services and their associated policies. WSRR, as a centralized services registry, enables service administrators to gain control and insight as to what is happening with deployed business services and consumers. For example, WSRR provides "impact analysis" reports that detail what consumer applications are affected if a specific service fails, changes, or is retired. You can import the reference implementation configuration (provided for download as part of this article) into WSRR and DataPower and use it immediately to enforce capabilities described here. You can modify the product configurations as needed to accommodate for different service and policy deployments' requirements. Finally, the 3-part series was created to allow for ease of migration between SLA Control File (Part 1) and WSRR models (this article) as much as possible. That way, you can start with the Part 1 approach and, when ready, migrate to use the WSRR tooling described in this article. Part 3 of the series documents the WSRR solution's DataPower configuration artifacts discussed in this article and provides step-by-step testing and validation instructions.Introduction
Integration between DataPower Appliance and WSRR service model
WSRR Artifacts Description Application Version The consuming application client version for the exposed DataPower appliance service. Service Version The providing service version that represents the exposed DataPower appliance backend service. SLA (service level agreement) The contract service level agreement between the consuming application and the backend service.
The SLA custom property is dp_slmPolicyName, which is the name of an SLM policy on the DataPower appliance that should be enforced as an SLA enforcement point. SLD (service level definition) The providing service contract agreement that documents the capabilities of the providing backend service. The SLD custom properties are:
SOAPServiceEndpoint The backend service endpoint for the SOAP Web Service provider. ServiceEndpoint The backend service endpoint for the XML/REST Web Service provider. WSDLDocument The WSDL document artifacts representing the backend SOAP service provider. XSDDocument The XSD schema document artifact representing the front and backend XML/REST service providers. Integration between DataPower and WSRR
Web-Service Proxy
WSRR components
DataPower configuration (WS-Proxy)
Versioning of SOAP-based services
dp_xformName_Request
property.
dp_xformName_Response
property.
<result> <inputSchema>wsrr://9.20.88.69/ges6gtes-b45d-5j98.g2k4.78673231b765/ </inputSchema> <outputSchema>wsrr://9.20.88.69/bef0cdbe-b41d-4d08.a5a5.54624854a539/ </outputSchema> </result>
<result>
nodeset returned in Action 1 is inspected by a conditional action. If it contains an <inputSchema>
element, DataPower validates the input. The <result>
element contains the bsrURI of the schema or WSDL to use in the schema validation. The bsrURI is obtained from the dp_xsd_frontEnd
property of the Service Version object in WSRR. Figure 10 shows the conditional and the validate actions that will run when the match condition is true. <result>
node from Action in 1 and look for the <outputSchema>
element to do a second validation if present. Figure 13 shows the conditional and the schema validate action that occurs if the schema value has been set. XML Gateway
WSRR components
DataPower configuration (MPGW)
Versioning of XML-based services
REST Gateway
WSRR components
DataPower configuration (MPGW)
Versioning of XML-based services
WSRR named queries used by sample stylesheets
SLACheckForOnlineEndpoint(consumerId, contextId)
https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/SLACheckForOnlineEndpoint?p1= OrderServiceConsumer001&p2=OrderServiceGold
https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/GetServiceSLD?p1= OrderServiceConsumer001&p2=OrderServiceGold
https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/GetFrontEndXSD?p1= 07f99f07-15c0-4099.b0c8.18ef6718c820
https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/GetBackEndSourceDocument? p1=OrderServiceConsumer001&p2=OrderServiceGold
https://9.20.88.69:9443/WSRR/7.5/Metadata/XML/Query/SLAOnlineEndpointLookup? p1=OrderServiceConsumer001&p2=OrderServiceGold
http://host:port/xmlEndpoint
with an endpoint type attribute of XML (Figure 52).Add OrderServiceSchema as sourceDocument of ServiceEndpoint
Classify and govern XML endpoint and add to the OrderService-SLD available endpoints
Scenario: REST endpoint
Create the REST ServiceEndpoint
http://host:port/restEndpoint
with an endpoint type attribute of "REST" (Figure 55).Classify and govern REST endpoint
Conclusion
Was this topic helpful?
Document Information
Modified date:
08 June 2021
UID
ibm11109571