We're considering deploying part of a new application using OE mobile, but not sure what is possible and not.
1) We have currently running SOAP web services to provide scheduling data, account balances, etc. to other applications and our own web applications. Can these be called using OE Mobile? From about 8 hours of messing around between two developers it appears one can only call a REST service - is there a way to call our SOAP services? For security and HIPAA reasons we don't want to connect to appservers or database servers.
2) This is a medical application and we'd like to use OE Mobile to capture a patient signature. Is this possible? Assume some sort of outside [plugin? widget? don't know what it would be called] would be needed. I don't even know which direction to start looking for this.
Thanks for any help. OE Mobile looks so easy, but we can't get anywhere at all so far ...
As John mentions, OE Mobile speaks REST, and has good built-in support for talking to an OE AppServer that knows how to provide REST/Mobile services. OE Mobile is an HTML client and could talk to your SOAP services (via a GET call or whatnot), but it's a fair amount of Work to work with XML in javascript (may not be complex, but adds a bunch of effort).
I'm assuming your SOAP services are ABL-based; in this case it is simple to annotate *existing* ABL procedures (and classes) in order to use them as Mobile services. PDSOE phas some wizards that will help with this (this is the functional equivalent of proxygen for REST/Mobile).
REST/Mobile services work at runtime in a similar manner to SOAP - the external exposure is via a Tomcat server, which passes the request through to an OE AppServer. In the case of Mobile services, OE provides some in-the-box security templates that you can use.
hth
REST only in OEMobile and its very easy to capture a signature using the canvas API
OpenEdge Mobile only has "automatic" support for REST, in terms of the Service definition page, but you do have access to JavaScript and could call anything you want. That being said, JavaScript client-side programming "standard" programming has more utilities and capabilities with JSON/HTTP than with SOAP/XML. I would recommend going to REST.
Actually, I would recommend using JSDO objects -- you could even call your WebServices from the AppServer and create the Business Entity that way (if some external system only had a Web Service interface).
I am not sure I understand your comment about "For security and HiPAA reasones we don't want to connect to appserver or database servers". The Mobile client goes over HTTP to a Web Server. The Web Server is what connects to the AppServer (and then the database). This is the same for Web Services / WSA -- there is no architectural difference in OpenEdge Mobile's use of JSON/HTTP vs a SOAP web service.
There are a number of JavaScript SOAP clients out there. This one, www.codeproject.com/.../JavaScript-SOAP-Client, creates a JavaScript proxy from the WSDL.
Having said that, if your SOAP services are from OE and the WSA, you should consider exposing them as REST. Unless you are operating in a session-managed mode, it shouldn't require any changes to your server code.
Hello,
You could probably write your own signature capture using the canvas API.
Just in case, I found a couple of plugins that implement signature capture. There may be others.
I have only tried them from a web browser and not tried to integrate them with an app:
- willowsystems.github.io/jSignature
- thomasjbradley.ca/.../signature-pad
You could check them out to see if they are suitable for your requirements.
Regards.
REST only in OEMobile and its very easy to capture a signature using the canvas API
As John mentions, OE Mobile speaks REST, and has good built-in support for talking to an OE AppServer that knows how to provide REST/Mobile services. OE Mobile is an HTML client and could talk to your SOAP services (via a GET call or whatnot), but it's a fair amount of Work to work with XML in javascript (may not be complex, but adds a bunch of effort).
I'm assuming your SOAP services are ABL-based; in this case it is simple to annotate *existing* ABL procedures (and classes) in order to use them as Mobile services. PDSOE phas some wizards that will help with this (this is the functional equivalent of proxygen for REST/Mobile).
REST/Mobile services work at runtime in a similar manner to SOAP - the external exposure is via a Tomcat server, which passes the request through to an OE AppServer. In the case of Mobile services, OE provides some in-the-box security templates that you can use.
hth
OpenEdge Mobile only has "automatic" support for REST, in terms of the Service definition page, but you do have access to JavaScript and could call anything you want. That being said, JavaScript client-side programming "standard" programming has more utilities and capabilities with JSON/HTTP than with SOAP/XML. I would recommend going to REST.
Actually, I would recommend using JSDO objects -- you could even call your WebServices from the AppServer and create the Business Entity that way (if some external system only had a Web Service interface).
I am not sure I understand your comment about "For security and HiPAA reasones we don't want to connect to appserver or database servers". The Mobile client goes over HTTP to a Web Server. The Web Server is what connects to the AppServer (and then the database). This is the same for Web Services / WSA -- there is no architectural difference in OpenEdge Mobile's use of JSON/HTTP vs a SOAP web service.
There are a number of JavaScript SOAP clients out there. This one, www.codeproject.com/.../JavaScript-SOAP-Client, creates a JavaScript proxy from the WSDL.
Having said that, if your SOAP services are from OE and the WSA, you should consider exposing them as REST. Unless you are operating in a session-managed mode, it shouldn't require any changes to your server code.
Thank you, all, for the useful information. Will give this a try, hopefully by week's end.
Hello,
You could probably write your own signature capture using the canvas API.
Just in case, I found a couple of plugins that implement signature capture. There may be others.
I have only tried them from a web browser and not tried to integrate them with an app:
- willowsystems.github.io/jSignature
- thomasjbradley.ca/.../signature-pad
You could check them out to see if they are suitable for your requirements.
Regards.
Thank you, egarcia, the jSignature plugin worked like a charm.
Anne