...
Warning |
---|
If using the formentry module 5.x and below with the Sync Module you must take care with how the concepts are developed. Formentry still depends on internal concept.concept_id values being the same on all servers. The sync module cannot guarantee that to be the case. So all concept/form development must happen on one and only one server in your sync network. This is also the case with Metadata Sharing Module. Work is underway to fix these problems. It is strongly recommended that you don't depend on sync to propagate changes to your infopath forms. PIH never did this successfully in Rwinkwavu, and this is one of the reasons that they transitioned completely to htmlforms. One problem is that infopath XSNs are .cab files that contain a whole bunch of files inside of them. Some of these files have the hard-coded paths of the server that you were working on when you modified the form. The problem is that these hard-coded strings then get propagated to the other servers through sync (when its working). In the past in Rwinkwavu, PIH ended up with forms from one site being submitted to another site, which caused all kinds of problems. Block org.openmrs.module.formentry at the parent sending level, and do all XSN manipulation by hand on each server. In the long run, this is still easier. |
...
- When using FormEntry Module in a non-Windows environment (one that uses cabextract), do not adjust Tomcat memory usage to greater than 4GB. See Ticket # FORM-14.
- See also ?Troubleshooting Formentry Module