Topic
  • 28 replies
  • Latest Post - ‏2012-07-09T16:29:56Z by GWReeves
GWReeves
GWReeves
103 Posts

Pinned topic JRules web service client

‏2012-06-20T13:11:11Z |
Using JRules 7.1.1

I am using a Java xom and have generated a web service client to invoke my rules via web service calls.

Inside my web service project I see the rule app as a jar file.

As far as I can see this means if I change my rules and redeploy my rule app the changed rules will not
be run unless I also regenerate my web service client and redeploy that too.

Am I missing something here? Is JRules rea
Updated on 2012-07-09T16:29:56Z at 2012-07-09T16:29:56Z by GWReeves
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-20T13:13:03Z  
    Sorry, message posted before I finished my sentence...

    Is JRules really running the rules from within the web service jar rather than thos deployed?

    Thanks,
    Glyn
  • arahant
    arahant
    17 Posts

    Re: JRules web service client

    ‏2012-06-20T19:42:57Z  
    • GWReeves
    • ‏2012-06-20T13:13:03Z
    Sorry, message posted before I finished my sentence...

    Is JRules really running the rules from within the web service jar rather than thos deployed?

    Thanks,
    Glyn
    Typically, a ruleapp is deployed to the Rule Execution Server. In your case, it looks like you have the ruleset embedded in the web service...this is usually not the recommended deployment. Not sure what you mean by "...rather than thos deployed?" Deployed where???

    Coming to your question...no, the client does not have to be regenerated. But the web service will have to be redeployed when you update the rules. This can be avoided by not embedding the ruleset in the web service.
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-22T15:51:08Z  
    • arahant
    • ‏2012-06-20T19:42:57Z
    Typically, a ruleapp is deployed to the Rule Execution Server. In your case, it looks like you have the ruleset embedded in the web service...this is usually not the recommended deployment. Not sure what you mean by "...rather than thos deployed?" Deployed where???

    Coming to your question...no, the client does not have to be regenerated. But the web service will have to be redeployed when you update the rules. This can be avoided by not embedding the ruleset in the web service.
    Thanks. I think by deployed I meant the rules as in the rules app itself
    (rather than the jar in the web service).

    I created a hello world app plus a web service client and tried various things out.

    The web service client generator creates two projects: a web service to invoke rules
    and a client. I've been using the web service (maybe this is where I'm going wrong).

    Anyway...

    It seems that the web service generated by Rule Studio includes the rule app as a jar
    and will run these rules if this jar is present. If the jar is removed from the web service
    the rules from the rule app will be used.

    So, by removing the jar from the generated web service it behaves as I would expect.
    I need to look further to see if whether the jar is included or not is an option
    when generating the web service. Meanwhile...

    As well as the rule app jar, the web service includes jrules jars (e.g. jrules-res-execution.jar).

    I'm still confused as to why, if I'm executing deployed rules, this is in the web service.

    More to the point, I've started getting the error: "Default connection manager pool is full"
    and the way to fix this is by added a pool-size parameter in the ra.xml.

    But now, I'm wondering, is the execution engine really the one on the res server or is it
    using what's bundled in the web service? So which ra.xml do I change?

    I was beginning to think that I had missed the point of the web service generator and that
    it was in fact designed to build stand-alone web services (i.e. everything, rules and rule
    engine) bundled in the same web service. But, when I removed the rule app from the server
    the web service failed.

    Am I totally missing the point of the web service client generator?

    Should I be looking at the web service client rather than the web service?
    (I notice the generated web service client also contains the rule app jar.)

    Any light anyone can shine on this subject would be very helpful.

    Thanks,
    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-22T17:11:03Z  
    • GWReeves
    • ‏2012-06-22T15:51:08Z
    Thanks. I think by deployed I meant the rules as in the rules app itself
    (rather than the jar in the web service).

    I created a hello world app plus a web service client and tried various things out.

    The web service client generator creates two projects: a web service to invoke rules
    and a client. I've been using the web service (maybe this is where I'm going wrong).

    Anyway...

    It seems that the web service generated by Rule Studio includes the rule app as a jar
    and will run these rules if this jar is present. If the jar is removed from the web service
    the rules from the rule app will be used.

    So, by removing the jar from the generated web service it behaves as I would expect.
    I need to look further to see if whether the jar is included or not is an option
    when generating the web service. Meanwhile...

    As well as the rule app jar, the web service includes jrules jars (e.g. jrules-res-execution.jar).

    I'm still confused as to why, if I'm executing deployed rules, this is in the web service.

    More to the point, I've started getting the error: "Default connection manager pool is full"
    and the way to fix this is by added a pool-size parameter in the ra.xml.

    But now, I'm wondering, is the execution engine really the one on the res server or is it
    using what's bundled in the web service? So which ra.xml do I change?

    I was beginning to think that I had missed the point of the web service generator and that
    it was in fact designed to build stand-alone web services (i.e. everything, rules and rule
    engine) bundled in the same web service. But, when I removed the rule app from the server
    the web service failed.

    Am I totally missing the point of the web service client generator?

    Should I be looking at the web service client rather than the web service?
    (I notice the generated web service client also contains the rule app jar.)

    Any light anyone can shine on this subject would be very helpful.

    Thanks,
    Glyn
    Hello,

    The MTDS web service generated by the Rule Studio is a J2SE one. that means the XU is embedded in the web service itself. In that case the ra.xml embedded must be adapted to use a datasource rather than the local res_data folder.

    What application server are you using to run the web service?

    Alain
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-22T17:44:01Z  
    Hello,

    The MTDS web service generated by the Rule Studio is a J2SE one. that means the XU is embedded in the web service itself. In that case the ra.xml embedded must be adapted to use a datasource rather than the local res_data folder.

    What application server are you using to run the web service?

    Alain
    Hello Alain,
    We are using JBoss 5.1 EAP.
    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-22T17:59:12Z  
    • GWReeves
    • ‏2012-06-22T17:44:01Z
    Hello Alain,
    We are using JBoss 5.1 EAP.
    Glyn
    There are 3 ways to install/use a XU in any application server:
    1 - as a global resource adapter (you put the .rar + -ds.xml into the jboss directory)
    2 - as a "local" resource adapter (you embed the .rar into a .ear)
    3 - as a API (you put the jrules-execution.jar into a .ear for example)

    The case 3) is what Alain is calling "J2SE".
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-22T18:01:45Z  
    Hello,

    The MTDS web service generated by the Rule Studio is a J2SE one. that means the XU is embedded in the web service itself. In that case the ra.xml embedded must be adapted to use a datasource rather than the local res_data folder.

    What application server are you using to run the web service?

    Alain
    Alain,
    I thought it looked like the XU was in the web service, but I didn't know why.
    I'm not sure why you would want to deploy lots of XUs rather than use the one
    on the server. Is that the normal way of using JRules? Are there disadvantages
    to using a single XU. I guess I'm thinking of the XU as a server rather than
    what it really is, which is an app. Or am I wrong? I'm certainly confused.
    Glyn
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-22T18:19:55Z  
    There are 3 ways to install/use a XU in any application server:
    1 - as a global resource adapter (you put the .rar + -ds.xml into the jboss directory)
    2 - as a "local" resource adapter (you embed the .rar into a .ear)
    3 - as a API (you put the jrules-execution.jar into a .ear for example)

    The case 3) is what Alain is calling "J2SE".
    Hmmm. I think I've got both 1 and 3.

    I've configured the JBoss server with the .rar and .ds.xml and apps deploy fine.
    I can inspect them via the console and even see run statistics for my rules when I run them.

    With an xsd model you can just go to the server and say give me the wsdl and away you go.

    Problem is, we are using java models (apparently 10 times faster) and you can't retrieve
    wsdl in the same way.

    I thought the web services client was to fill this gap by allowing you to generate a
    wrapper web service that sits on the server and acts as an interface between your rules
    and your consumming client app.

    But it looks like I've totally misunderstood it's purpose.

    So I guess my question is, how are other people invoking JRules? Does anyone invoke
    via web service calls? If they do, how are they doing it?

    There's something fundamental that I'm just not getting about this.

    Any explanation would be appreciated.

    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-22T18:20:31Z  
    • GWReeves
    • ‏2012-06-22T18:01:45Z
    Alain,
    I thought it looked like the XU was in the web service, but I didn't know why.
    I'm not sure why you would want to deploy lots of XUs rather than use the one
    on the server. Is that the normal way of using JRules? Are there disadvantages
    to using a single XU. I guess I'm thinking of the XU as a server rather than
    what it really is, which is an app. Or am I wrong? I'm certainly confused.
    Glyn
    Each XU has its own caches. If you have multiple applications using ruleset execution, you may want to use a unique XU to reduce the memory footprint. But you may also want to isolate the resources for each application. For example to avoid the case that one application with a high frequency usage is filling the cache unlike the other application which has a low frequence of execution requests.

    You cannot deploy multiple XUs of different JRules versions as global resource adapters. Here again, it can be useful to deploy the XU as a local resource adapeter or use it as a "J2SE API".

    You may want to use the XU in a J2EE Application Server which is not supported. As a "J2SE API" you can use it in any application servers, the requirement is just the version of the JDK.

    etc.

    In order to address the more possible type of needs, 3 differents ways of deploying/using the XU is offered.
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-22T18:36:29Z  
    Each XU has its own caches. If you have multiple applications using ruleset execution, you may want to use a unique XU to reduce the memory footprint. But you may also want to isolate the resources for each application. For example to avoid the case that one application with a high frequency usage is filling the cache unlike the other application which has a low frequence of execution requests.

    You cannot deploy multiple XUs of different JRules versions as global resource adapters. Here again, it can be useful to deploy the XU as a local resource adapeter or use it as a "J2SE API".

    You may want to use the XU in a J2EE Application Server which is not supported. As a "J2SE API" you can use it in any application servers, the requirement is just the version of the JDK.

    etc.

    In order to address the more possible type of needs, 3 differents ways of deploying/using the XU is offered.
    Thanks, so what I've current got sounds like, possibly, a workable solution.

    Does this sound like the procedure (bearing in mind we are not authoring rules on RTS yet)...
    I develope my rules and deploy the rule app to the server.

    Then I create a web service (using the web services client wizard).

    Then I remove the rules app jar from the web service but leave the other jars (jrules-res etc.) in there.

    I change the ra.xml in the web service (a bit more homework to do for the exact details).

    Then I deploy the web service to the server.

    When the rules are executed (by calling the web service) the rules from the deployed rule app are used
    and the XU from the web service is used to run them.

    When the rules are changed (without a change to the inputs or outputs) only the rule app need be redeployed.

    If the bom changes (e.g. a new input field is added) the web service will need recreating as above.

    Does this sound like a workable procedure?

    Thanks,
    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-22T20:40:41Z  
    • GWReeves
    • ‏2012-06-22T18:36:29Z
    Thanks, so what I've current got sounds like, possibly, a workable solution.

    Does this sound like the procedure (bearing in mind we are not authoring rules on RTS yet)...
    I develope my rules and deploy the rule app to the server.

    Then I create a web service (using the web services client wizard).

    Then I remove the rules app jar from the web service but leave the other jars (jrules-res etc.) in there.

    I change the ra.xml in the web service (a bit more homework to do for the exact details).

    Then I deploy the web service to the server.

    When the rules are executed (by calling the web service) the rules from the deployed rule app are used
    and the XU from the web service is used to run them.

    When the rules are changed (without a change to the inputs or outputs) only the rule app need be redeployed.

    If the bom changes (e.g. a new input field is added) the web service will need recreating as above.

    Does this sound like a workable procedure?

    Thanks,
    Glyn
    Hello,

    I would recommend to change the generated code of the webservice and use a simple rule session provider. Remove all JRules jars and use only jrules-res-session-java.jar. Also remove the ra.xml not useful if you are using the XU deployed on JBOSS.
    In the web.xml make sure to add a resource reference to the connection factory xu_cf.

    You will need to change the webservice only if the parameters are changed. Any change in the bom or the rules that does not impact the type of the parameters.

    Alain
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-25T15:33:29Z  
    Hello,

    I would recommend to change the generated code of the webservice and use a simple rule session provider. Remove all JRules jars and use only jrules-res-session-java.jar. Also remove the ra.xml not useful if you are using the XU deployed on JBOSS.
    In the web.xml make sure to add a resource reference to the connection factory xu_cf.

    You will need to change the webservice only if the parameters are changed. Any change in the bom or the rules that does not impact the type of the parameters.

    Alain
    Thanks Alain.
    I'm giving it a go. I'm afraid I may have more questions though.
    Glyn
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-26T10:05:17Z  
    Hello,

    I would recommend to change the generated code of the webservice and use a simple rule session provider. Remove all JRules jars and use only jrules-res-session-java.jar. Also remove the ra.xml not useful if you are using the XU deployed on JBOSS.
    In the web.xml make sure to add a resource reference to the connection factory xu_cf.

    You will need to change the webservice only if the parameters are changed. Any change in the bom or the rules that does not impact the type of the parameters.

    Alain
    Alain,
    Sorry, I've done the other changes but how do I "add a resource reference to the connection factory xu_cf"?
    Thanks,
    Glyn
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-27T13:32:48Z  
    Hello,

    I would recommend to change the generated code of the webservice and use a simple rule session provider. Remove all JRules jars and use only jrules-res-session-java.jar. Also remove the ra.xml not useful if you are using the XU deployed on JBOSS.
    In the web.xml make sure to add a resource reference to the connection factory xu_cf.

    You will need to change the webservice only if the parameters are changed. Any change in the bom or the rules that does not impact the type of the parameters.

    Alain
    Alain,

    For the web.xml change, does this look right?...

    <resource-ref>
    <res-ref-name>eis/XUConnectionFactory</res-ref-name>
    <res-type>javax.resource.cci.ConnectionFactory</res-type>
    <res-auth>Application</res-auth>
    <res-sharing-scope>Unshareable</res-sharing-scope>
    </resource-ref>

    I tried using a simple rule session provider but couldn't find a non-J2SE version and also all the methods and classes are deprecated. The java documentation says use a factory instead but it doesn't don't say what the replacement classes and interfaces are. I've tried trawling the javadoc tree but not found it. Any chance you could drop me another hint?

    Thanks,
    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-27T13:51:02Z  
    • GWReeves
    • ‏2012-06-27T13:32:48Z
    Alain,

    For the web.xml change, does this look right?...

    <resource-ref>
    <res-ref-name>eis/XUConnectionFactory</res-ref-name>
    <res-type>javax.resource.cci.ConnectionFactory</res-type>
    <res-auth>Application</res-auth>
    <res-sharing-scope>Unshareable</res-sharing-scope>
    </resource-ref>

    I tried using a simple rule session provider but couldn't find a non-J2SE version and also all the methods and classes are deprecated. The java documentation says use a factory instead but it doesn't don't say what the replacement classes and interfaces are. I've tried trawling the javadoc tree but not found it. Any chance you could drop me another hint?

    Thanks,
    Glyn
    Hello,

    Yes the resource reference is what you need. You are following this model and you need to use this class IlrPOJOSessionFactory to create your session.

    Note that if you plan to create multiple webservices with this method, once you have written the code that works I would suggest you change the template of the generator so that the code created is ready to use.
    The files used by the wizard to generate the code are found in this location
    <jrules>\studio\eclipse\plugins\ilog.rules.studio.res_7.1.1.4\templates\webservice

    You can edit the file BeanImpl.vm and change the code of getFactory for example. The format of the files in the templates is velocity, $ sign is used to indicate variables.

    My 2 cents,
    Alain
    Alain
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-27T14:42:26Z  
    Hello,

    Yes the resource reference is what you need. You are following this model and you need to use this class IlrPOJOSessionFactory to create your session.

    Note that if you plan to create multiple webservices with this method, once you have written the code that works I would suggest you change the template of the generator so that the code created is ready to use.
    The files used by the wizard to generate the code are found in this location
    <jrules>\studio\eclipse\plugins\ilog.rules.studio.res_7.1.1.4\templates\webservice

    You can edit the file BeanImpl.vm and change the code of getFactory for example. The format of the files in the templates is velocity, $ sign is used to indicate variables.

    My 2 cents,
    Alain
    Alain
    Alain,
    Thanks again. The more I read the more confused I get.
    It seems to me that we would want to use stateless sessions which is what the POJO Session Factory delivers. I'm putting my flippers on and diving in for another go. A good tip on adapting the wizard.
    I'm a big fan of automating tasks where possible.
    Thanks again,
    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-27T15:10:10Z  
    • GWReeves
    • ‏2012-06-27T14:42:26Z
    Alain,
    Thanks again. The more I read the more confused I get.
    It seems to me that we would want to use stateless sessions which is what the POJO Session Factory delivers. I'm putting my flippers on and diving in for another go. A good tip on adapting the wizard.
    I'm a big fan of automating tasks where possible.
    Thanks again,
    Glyn
    Hi,

    That's right you will want to use the tateless session and this is what the generated codes uses already.

    From what I can see in the generated code I believe once you change the method getFactory in the beanImpl.java file and use the POJO session factory you won't have much more change to perform in the code.
    The rest is about packaging the right jars.
    Alain
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-27T16:05:43Z  
    Hi,

    That's right you will want to use the tateless session and this is what the generated codes uses already.

    From what I can see in the generated code I believe once you change the method getFactory in the beanImpl.java file and use the POJO session factory you won't have much more change to perform in the code.
    The rest is about packaging the right jars.
    Alain
    Alain,

    Thanks. What I did was add a method in the RunnerImpl but your suggestion is the better way to go long-term.

    But, now when I run I get...
    mapped-name is required for eis/XUConnectionFactory

    Sounds like I have to add this entry to another xml file (or create one?) but I'm not sure which and what the
    new entry would need to look like.

    Any hints?

    Thanks,
    Glyn

    Sorry, it's nearly there.:)
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-27T19:46:38Z  
    • GWReeves
    • ‏2012-06-27T16:05:43Z
    Alain,

    Thanks. What I did was add a method in the RunnerImpl but your suggestion is the better way to go long-term.

    But, now when I run I get...
    mapped-name is required for eis/XUConnectionFactory

    Sounds like I have to add this entry to another xml file (or create one?) but I'm not sure which and what the
    new entry would need to look like.

    Any hints?

    Thanks,
    Glyn

    Sorry, it's nearly there.:)
    Sounds good!

    I believe you need a jboss-web.xml with something like that:

    <?xml version='1.0' encoding='UTF-8' ?>
    <!DOCTYPE jboss-web
    PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">

    <jboss-web>
    <resource-ref>
    <res-ref-name>eis/XUConnectionFactory</res-ref-name>
    <jndi-name>java:/eis/XUConnectionFactory</jndi-name>
    </resource-ref>
    </jboss-web>

    Alain
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-28T11:15:18Z  
    Sounds good!

    I believe you need a jboss-web.xml with something like that:

    <?xml version='1.0' encoding='UTF-8' ?>
    <!DOCTYPE jboss-web
    PUBLIC "-//JBoss//DTD Web Application 2.3V2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-web_3_2.dtd">

    <jboss-web>
    <resource-ref>
    <res-ref-name>eis/XUConnectionFactory</res-ref-name>
    <jndi-name>java:/eis/XUConnectionFactory</jndi-name>
    </resource-ref>
    </jboss-web>

    Alain
    Alain,

    Thanks. I tried that but it still couldn't find it. I got...
    "Could not dereference object ilog.rules.res.util.IlrRemoteException: eis not bound"

    Does this imply that something else needs adding to the server itself?

    Just to clarify, this is what I did...
    I editted the jboss-web.xml in my web service, rebuilt and redeployed.

    Any suggestions?

    Thanks,
    Glyn
  • SystemAdmin
    SystemAdmin
    1730 Posts

    Re: JRules web service client

    ‏2012-06-28T14:18:31Z  
    • GWReeves
    • ‏2012-06-28T11:15:18Z
    Alain,

    Thanks. I tried that but it still couldn't find it. I got...
    "Could not dereference object ilog.rules.res.util.IlrRemoteException: eis not bound"

    Does this imply that something else needs adding to the server itself?

    Just to clarify, this is what I did...
    I editted the jboss-web.xml in my web service, rebuilt and redeployed.

    Any suggestions?

    Thanks,
    Glyn
    Hi,

    looks like a problem with the XU itself. as if it was not deployed. Can you check with the JBoss admin console if the jndi name is visible?

    Alain
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-06-28T16:18:24Z  
    Hi,

    looks like a problem with the XU itself. as if it was not deployed. Can you check with the JBoss admin console if the jndi name is visible?

    Alain
    Alain,
    Thanks for your reply. Unfortunately or fortunately, depending on how you view it,
    I have the day off tomorrow so I will have a look at this next week.
    Thanks again for your help. I'll let you know what I find on Monday.
    Thanks,
    Glyn
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-07-09T10:29:25Z  
    Hi,

    looks like a problem with the XU itself. as if it was not deployed. Can you check with the JBoss admin console if the jndi name is visible?

    Alain
    Alain,
    The dust has settled and I'm able to return to JRules web services.
    I've had a trawl around the JBoss admin console and can se no "eis"
    but I'm not very familiar with JBoss (used mostly WebSphere) so I'm
    not sure exactly where I would expect to find it if it was there.
    Sorry to ask to be spoon-fed again but you wouldn't happen to know
    where the setting would be if it was there would you?
    Thanks,
    Glyn
  • GWReeves
    GWReeves
    103 Posts

    Re: JRules web service client

    ‏2012-07-09T14:14:04Z  
    Hi,

    looks like a problem with the XU itself. as if it was not deployed. Can you check with the JBoss admin console if the jndi name is visible?

    Alain
    Alain,

    I spotted that there was a jndi reference in: jrules-res-xu-JBOSS5-ds.xml
    I copied it to the server and rebooted. It looks like a step in the right
    direction but still not quite there.

    I'm getting...

    ilog.rules.res.session.IlrSessionCreationException: An error occurred while the rule session was created.
    ilog.rules.res.util.IlrRemoteException: XU JNDI name java:comp/env/eis/XUConnectionFactory does not reference a XU connection factory

    So it looks like now it can find the eis jndi entry but still can't follow it to the XU connection factory.

    The xml reffers to jrules-res-xu-JBOSS5.rar which is deployed to the server.

    I'm not able to open the rar file (WinZip says it's not a valid rar file).

    I also noticed the javax.resource.cci.ConnectionFactory referred to in the xml is in j2ee_connector-1_5-fr.jar
    and is an interface. There is a concrete implementation: ilog.rules.res.xu.cci.IlrXUConnectionFactory

    Do you think I should change the xml to point to this?

    Thanks,
    Glyn