DataPower

Ajey,

Look into count, duration and service monitors, but maybe more importantly SLM policies.   Count monitors can shape or even throttle traffic based upon a number of errors occurring.  Duration monitors do the same, except they're related more to how long things are taking.   Service monitors are more closely related to SOAP traffic, so this one may not apply here.

SLM policies, however, are very advanced, allowing shaping and throttling under a wide variety of purposes and can be scheduled.  So, if you have a standard change window where deployments occur, you can set different conditions during that time than the normal time.

Hi Joseph,

          Thanks for update on SLM and Monitors,

          we have implemented both the pattern and shown demo to L3 Team,

          1.SLM we applied as a throttle to reject with customized response ,

          2.For Monitor we have applied error rule to increment the monitor count and again in the request rule for last 60 mins if the count increase above 6000 we are applying skip-back side.

SOMA call:

                   <xsl:variable name="dataload">
                   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:man="http://www.datapower.com/schemas/management">
                      <soapenv:Header/>
                      <soapenv:Body>
                         <man:request domain="webDataPower">
                            <man:get-status class="MessageCounts"/>
                         </man:request>
                      </soapenv:Body>
                   </soapenv:Envelope>
                   </xsl:variable>                  
                   <xsl:variable name="result" select="dp:soap-call('https://x.x.x.x:5550/service/mgmt/2004', $dataload, 'client:clientSSLProfile', 0, 'action', $httpHeaders)"/>
       <xsl:variable name="dataResult" select="$result//MessageCounts/Type[text()='valueMon_1']/following-sibling::tenSeconds"/>

Challenge we have is for monitor increment we have extension variable to increment the integer,
where as to get the monitor count for 10sec and one min we are not seeing any extension variable.
Incase we have any extension function to get the monitor count , please let me know.

------------------------------------
Ajey chekravarthi
------------------------------------

Yes.  Look at https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=elements-dpincrement-integer

Edit:  I think I misunderstood.  You want to get the value of the monitor.  In your code?  What will you do with the value?   The configurations of the count/duration/SLM monitors are designed to more than likely handle the needs of the requirement.

Hi Joseph,

               Thank you for sharing the link - with dp:increment we are able to update the statistic record,

               where as with out SOMA call any other way is there to get the 10mins , 1 hours report in the xslt.

               [eg:] <dp:increment-integer name="'/monitor-count/valueMon'"/>     is increament

                      <dp:get-integer name="'/monitor-count/valueMon'" timing="'10s'"/>   to get the 10sec data ?

Counter data:

You want to get the value of the monitor. 

In your code? yes 

What will you do with the value?  For last 1 min timed-out value will be increased on error xslt and will get the value on request and apply the skip-back side (or) dp:reject.
instead of wait/stall connection triggered until the time-out value completed for each transaction.

Sample :

                   <xsl:choose>
                            <xsl:when test="$dataResult &gt; '2'">
                                     <dp:reject>cutomized001</dp:reject> <!--  [OR] <dp:set-variable name="'var://service/mpgw/skip-backside'" value="1"/>  -->                                 
                            </xsl:when>
                   </xsl:choose>

----------------------

Ajey chekravarthi
----------------------

Ajey,

I realized I had misunderstood the question on my first response and tried to edit afterwards.

I'm curious why you need to do this?  The status numbers aren't going to be reliable, I don't think, for your use case.   The Count/Duration/SLM configurations should be able to solve for any actions you need to take.

Checking your initial question, what is it you want to accomplish?

Ugh.  Now our messages are crossing on the wire.

This is somewhat the purpose of the SLM.  When the SLM causes a rejection, configure an error rule to respond how you want.   You shouldn't need to explicitly skip the back side.

Hi Joseph,

         Thank you we will go with SLM.

------------------------------------
Ajey chekravarthi
------------------------------------