Although my 'sendMailToRoles' service works, I'm getting the following
error: Passed following params to 'sendMailToRoles' [sendFrom=[hidden email], roles=[CTO], subject=Test to CTO at Thu Apr 2 7 23:21:40 BST 2006, body=Testing, locale=en_GB] 23:21:44,442 (org.ofbiz.service.job.JobPoller@135877f) [XAConnectionFactory.java:119:WARN ] no xares in rms for con org.ofbi z.minerva.pool.jdbc.xa.wrapper.XAConnectionImpl@14a9387 23:21:46,304 (Thread-35) [ ModelService.java:396:ERROR] [ModelService.validate] : {sendMailToRoles} : (OUT) Required t est error: org.ofbiz.service.ServiceValidationException: The following required parameter is missing: [sendMailToRoles.body] The following required parameter is missing: [sendMailToRoles.subject] 23:21:46,324 (Thread-35) [ ServiceDispatcher.java:366:ERROR] ---- exception report ---------------------------------------------------------- Outgoing result (in runSync : sendMailToRoles) does not match expected requirements Exception: org.ofbiz.service.ServiceValidationException Message: The following required parameter is missing: [sendMailToRoles.body]The following required parameter is missing: [se ndMailToRoles.subject] ---- stack trace --------------------------------------------------------------- org.ofbiz.service.ServiceValidationException: The following required parameter is missing: [sendMailToRoles.body]The followi ng required parameter is missing: [sendMailToRoles.subject] org.ofbiz.service.ModelService.validate(ModelService.java:438) org.ofbiz.service.ModelService.validate(ModelService.java:393) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:364) org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:213) org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:110) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) You can see from the above that the parameters *are* being passed (they must be - i'm getting the mail ;-)) Could this be something to do with the fact that i'm calling sendMail in this in a loop (don't knowif this is correct)? Iterator i = emailSet.iterator(); while (i.hasNext()) { Map emailToSend = (Map) i.next(); /* * Merge the entries for each email to send with * the original context parameters, allowing the * latter to be overwritten */ context.putAll(emailToSend); EmailServices.sendMail(ctx, context); /* if (bStoreEmailAsCommunication) { EmailServices.storeEmailAsCommunication(ctx, context); }*/ } CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Charles,
Could it be that the error doesn't refer to the same iteration of your emailSet that is delivering successfully to you? Also, it looks like the service is complaining about the "OUT" parameters, not the "IN" ones. Check your servicedef, there are three modes for a service attribute IN / OUT / INOUT -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Andrew Sykes wrote: >Charles, > >Could it be that the error doesn't refer to the same iteration of your >emailSet that is delivering successfully to you? > >Also, it looks like the service is complaining about the "OUT" >parameters, not the "IN" ones. Check your servicedef, there are three >modes for a service attribute IN / OUT / INOUT > > >> Could it be that the error doesn't refer to the same iteration of your emailSet that is delivering successfully to you? >> I don't think so, since it happens with a single item in the loop. I'll check the IN/OUT parameters - not really 100% sure how that works anyway. C. _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Charles,
> I'll check the IN/OUT parameters - not really 100% sure how that works anyway. A quick summary... OFBiz services take and return a Map of values, input values are validated before the service is run and output values are validated after the service runs. The services.xml (called this by convention - not imperative) file is used to define the input and output parameters as well as their type, so the definition of a parameter looks something like this... <attribute name="myvalue" type="String" mode="IN" optional="true"/> "myvalue" is the name you assign to your parameter. e.g. when compiling the input map you might do something like inputMap.put("myvalue",new String("This is my input value")); "type" is the java type, any java type is allowed here (e.g. java.util.List ) "mode" can be either... IN input parameter only OUT output parameter only INOUT used as both an input and output parameter "optional" if set to false then service validation will fail if the parameter is missing. I hope that helps. -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Charles, Which version of OFBiz are you using? If I remember right this was a problem a long time ago but is no longer. -David Andrew Sykes wrote: > Charles, > >> I'll check the IN/OUT parameters - not really 100% sure how that works anyway. > > A quick summary... > > OFBiz services take and return a Map of values, input values are > validated before the service is run and output values are validated > after the service runs. > > The services.xml (called this by convention - not imperative) file is > used to define the input and output parameters as well as their type, so > the definition of a parameter looks something like this... > > <attribute name="myvalue" type="String" mode="IN" optional="true"/> > > "myvalue" is the name you assign to your parameter. > e.g. when compiling the input map you might do something like > inputMap.put("myvalue",new String("This is my input value")); > > "type" is the java type, any java type is allowed here (e.g. > java.util.List ) > > "mode" can be either... > IN input parameter only > OUT output parameter only > INOUT used as both an input and output parameter > > "optional" if set to false then service validation will fail if the > parameter is missing. > > I hope that helps. _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
David E Jones wrote: >Charles, > >Which version of OFBiz are you using? If I remember right this was a problem a long time ago but is no longer. > >-David > > > >Andrew Sykes wrote: > > >>Charles, >> >> >> >>>I'll check the IN/OUT parameters - not really 100% sure how that works anyway. >>> >>> >>A quick summary... >> >>OFBiz services take and return a Map of values, input values are >>validated before the service is run and output values are validated >>after the service runs. >> >>The services.xml (called this by convention - not imperative) file is >>used to define the input and output parameters as well as their type, so >>the definition of a parameter looks something like this... >> >><attribute name="myvalue" type="String" mode="IN" optional="true"/> >> >>"myvalue" is the name you assign to your parameter. >> e.g. when compiling the input map you might do something like >> inputMap.put("myvalue",new String("This is my input value")); >> >>"type" is the java type, any java type is allowed here (e.g. >>java.util.List ) >> >>"mode" can be either... >> IN input parameter only >> OUT output parameter only >> INOUT used as both an input and output parameter >> >>"optional" if set to false then service validation will fail if the >>parameter is missing. >> >>I hope that helps. >> >> > >_______________________________________________ >Users mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/users > > > > >>Which version of OFBiz are you using? 6860. I'd be grateful if you could advise reasonably quickly before i waste too much time ;-) CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
In reply to this post by Andrew Sykes
Andrew Sykes wrote: >Charles, > > > >>I'll check the IN/OUT parameters - not really 100% sure how that works anyway. >> >> > >A quick summary... > >OFBiz services take and return a Map of values, input values are >validated before the service is run and output values are validated >after the service runs. > >The services.xml (called this by convention - not imperative) file is >used to define the input and output parameters as well as their type, so >the definition of a parameter looks something like this... > ><attribute name="myvalue" type="String" mode="IN" optional="true"/> > >"myvalue" is the name you assign to your parameter. > e.g. when compiling the input map you might do something like > inputMap.put("myvalue",new String("This is my input value")); > >"type" is the java type, any java type is allowed here (e.g. >java.util.List ) > >"mode" can be either... > IN input parameter only > OUT output parameter only > INOUT used as both an input and output parameter > >"optional" if set to false then service validation will fail if the >parameter is missing. > >I hope that helps. > > Andrew, Thanks for the clues about that. Setting those parameters in my result Map cured the problem CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
In reply to this post by David E. Jones
David E Jones wrote: >Charles, > >Which version of OFBiz are you using? If I remember right this was a problem a long time ago but is no longer. > >-David > > > >Andrew Sykes wrote: > > >>Charles, >> >> >> >>>I'll check the IN/OUT parameters - not really 100% sure how that works anyway. >>> >>> >>A quick summary... >> >>OFBiz services take and return a Map of values, input values are >>validated before the service is run and output values are validated >>after the service runs. >> >>The services.xml (called this by convention - not imperative) file is >>used to define the input and output parameters as well as their type, so >>the definition of a parameter looks something like this... >> >><attribute name="myvalue" type="String" mode="IN" optional="true"/> >> >>"myvalue" is the name you assign to your parameter. >> e.g. when compiling the input map you might do something like >> inputMap.put("myvalue",new String("This is my input value")); >> >>"type" is the java type, any java type is allowed here (e.g. >>java.util.List ) >> >>"mode" can be either... >> IN input parameter only >> OUT output parameter only >> INOUT used as both an input and output parameter >> >>"optional" if set to false then service validation will fail if the >>parameter is missing. >> >>I hope that helps. >> >> > >_______________________________________________ >Users mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/users > > > > I fixed it thanks (see my reply to Andrew) but are you implying in any way that my remedial action should no longer be necessary? CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
In reply to this post by Charles Johnson-2
Charles,
That's great! How did you go about this in the end? Did you manage to debug the existing functionality, or have you written some new stuff? If you've found a bug, I'm sure everyone would be grateful for some pointers. -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Andrew Sykes wrote: >Charles, > >That's great! > >How did you go about this in the end? Did you manage to debug the >existing functionality, or have you written some new stuff? > >If you've found a bug, I'm sure everyone would be grateful for some >pointers. > > the end of the chain (storeEmailAsCommunication) but this may be due to the way i'm calling it. I'm (sendToRoles) at the beginning of the chain and i call EmailServices.sendMail statically in the same module. Probably also incorrect are the xml service definitions. I should really choose whether or not the end of the chain is required to be reached by the service parameters CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Charles,
The definition for storeEmailAsCommunication is: Service Name: storeEmailAsCommunication Description: Store email as a communication event with the status COM_COMPLETE. The communication event will be from the party of the userLogin to the party of the partyId parameter. It is meant to run a SECA after a sendMail to record outgoing emails. Exportable: False The important point to notice is "It is meant to run a SECA after a sendMail to record outgoing emails." In case you haven't come across SECAs yet, here's a quick definition... SECA = Service Event Condition Action A SECA is constituted of three parts, a Service Event, a Condition and an Action. Service Event = When a particular stage of execution is reached on the named service. Condition = When specific features of the data being processed are found. Action = A service to run In applications/content/servicedef/secas.xml, you will see a definition for sendMail that looks like this... <eca service="sendMail" event="commit"> <condition field-name="partyId" operator="is-not-empty"/> <action service="storeEmailAsCommunication" mode="sync"/> </eca> Each attribute is explained below eca service = sendMail event = one of... auth: on authorisation commit: on transaction commit global-commit: on global transaction commit global-rollback: on global transaction roll-back in-validate: on validation of 'IN' parameters invoke: on invocation of the service out-validate: on validation of 'OUT' parameters return: on service return (in each case these are run 'just before' the event) condition field-name = one of the 'IN' parameters operator = one of... contains equals greater greater-equals is-empty is-not-empty less less-equals not-equals Although not shown above some of these operators also require one of format/type/value attribute. action service: the service to call mode: one of sync: synchronous service call async: asynchronous service call >From all of the above, you can see that the SECA would only be called if partyId had a value. So, I guess that's the first thing to check. Let me know how you get on... -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Andrew Sykes wrote: >Charles, > >The definition for storeEmailAsCommunication is: > >Service Name: storeEmailAsCommunication >Description: Store email as a communication event with the status >COM_COMPLETE. The communication event will be from the party of the >userLogin to the party of the partyId parameter. It is meant to run a >SECA after a sendMail to record outgoing emails. >Exportable: False > >The important point to notice is "It is meant to run a SECA after a >sendMail to record outgoing emails." > >In case you haven't come across SECAs yet, here's a quick definition... > >SECA = Service Event Condition Action >A SECA is constituted of three parts, a Service Event, a Condition and >an Action. >Service Event = When a particular stage of execution is reached on the >named service. >Condition = When specific features of the data being processed are >found. >Action = A service to run > >In applications/content/servicedef/secas.xml, you will see a definition >for sendMail that looks like this... > ><eca service="sendMail" event="commit"> > <condition field-name="partyId" operator="is-not-empty"/> > <action service="storeEmailAsCommunication" mode="sync"/> ></eca> > >Each attribute is explained below > >eca >service = sendMail >event = one of... > auth: on authorisation > commit: on transaction commit > global-commit: on global transaction commit > global-rollback: on global transaction roll-back > in-validate: on validation of 'IN' parameters > invoke: on invocation of the service > out-validate: on validation of 'OUT' parameters > return: on service return > (in each case these are run 'just before' the event) > >condition >field-name = one of the 'IN' parameters >operator = one of... > contains > equals > greater > greater-equals > is-empty > is-not-empty > less > less-equals > not-equals >Although not shown above some of these operators also require one of >format/type/value attribute. > >action >service: the service to call >mode: one of > sync: synchronous service call > async: asynchronous service call > >>From all of the above, you can see that the SECA would only be called if >partyId had a value. > >So, I guess that's the first thing to check. Let me know how you get >on... > > I'm still not clear on what's providing the 'intelligence' here though. The condition and action are clearly defined here: <eca service="sendMail" event="commit"> <condition field-name="partyId" operator="is-not-empty"/> <action service="storeEmailAsCommunication" mode="sync"/> </eca> but what exactly is providing the inspection, validation and so on here? It would seem that it can't be only the Java implementation as that would detract from the strength of the ability to be declarative (as in the 'eca' element) and what's more the declaration could easily get out of synch with the implementation ... CJ _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Charles,
The 'intelligence' can be found in org.ofbiz.service.ServiceDispatcher.java There is nothing tying the eca definition to the java/bsh/minilang/some other remote implementation of the service, so yes it is possible to get things out of sync in terms of development iterations if you don't keep all the declarations up to date. However, the parameters are validated on both input and output, so you hopefully wouldn't get very far with an out-of-date declaration without throwing a Service Validation exception. I think that answers the question, but if I've left anything out, let me know. -- Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Free forum by Nabble | Edit this page |