1 / 20

MGHSURG MOSAIC Application upgrade to Cache Web Services

MGHSURG MOSAIC Application upgrade to Cache Web Services. MGH OR Group. Existing Application

tayte
Télécharger la présentation

MGHSURG MOSAIC Application upgrade to Cache Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MGHSURG MOSAIC Application upgrade to Cache Web Services MGH OR Group

  2. Existing Application MOSAIC (MGH OR Schedule And Information Center) - Intranet-based Web Schedule to improve and streamline access to OR scheduling-related information, and to eliminate the inefficient photocopying and distribution process saving the staff both time and money.

  3. Application details Implementation: DHTML Application processing data provided by WebLink XML Services. Problems: • Security: Existing HTML Application contains the actual WebLink URL and Parameters visible to the end user. • Resources: Limited resources to complete the work. • Dependencies: The WebLink XML Service is used by other applications within the hospital.

  4. Design Approach • To hide WebLink Service URL and parameters from end user. • Convert DHTML Application to ASP Application. • Hide WebLink Access in Server Side Script • Process only requests coming from a certain web page (via shared secret). Warning: If you have web application running on PPD Servers, converting DHTML Application to ASP Application and accessing WebLink XML Services on PPD via Server Side scripts will NOT WORK in production. It works fine in QA and Development.

  5. Design Approach (continued) • Convert WebLink XML Service to SOAP Web Service using Cache objects, querying existing legacy database. • Secure SOAP Web Service via ASG/Soap Station • Provide existing users with guidelines on how to convert to the new SOAP Web Service. • After all users have switched to the new SOAP based Web Service retire old WebLink XML Service. • Data Filtering by Account and/or Application (HIPPA Compliance, Audit, etc.)

  6. Our Approach to SOAP based Web Services using CACHE Objects? • Create Web Service using CACHE Web Service Wizard. Supports SOAP automatically. • Use Registered Objects with Support for XML to represent legacy data. This type of objects gave us more developer-friendly representation of packed data, and did not require conversion of existing legacy data. • Use/Alter existing routines to fill objects with data.

  7. Code Samples and walkthrough Create Web Service: From CACHE Studio using menu: File>New select Web Service

  8. Enter Web Service Details

  9. Click OK, and add methods to support required functionality.

  10. Create CACHE Object to represent XML Schema using the New Class Wizard You have the flexibility to separate different sets of data in packages by functionality, areas or business rules.

  11. Make sure that Registered is selected

  12. Specify that class supports XML

  13. When you click Finish, the new class is created and you are ready to add properties:

  14. In our design we used a Registered class to implement the IO routines. This helps us to keep the XML objects abstracted from actual IO processing code in case we need later to reuse objects, but use different data provider.

  15. The process of updating existing routines is simple mapping between object properties and existing xml tags in WebLink returned code.

  16. Performance Testing

  17. Recommendations • Map Legacy Data record to Object(s). • Separate DB Reading objects/routines from Data Objects. This will add flexibility when changing DB source, but preserves the XML Schema. • Apply additional filtering based on requirements (HIPPA, Audit, etc.)

  18. SOAP HTTP Request • Web Service Process flow Additional Services HIPPA Filter Audit Statistics Web Service O BJECT R E Q U E S t Registered objects with XML Support representing single Record in legacy DB I/O Routines DB Reader Object (s) POPULATE R E A D D A C Legacy DB A B C

  19. Summary WS Security Gateway (ASG/SOAP Station) Applications CACHE WEB SERVICES OBJECTS DHTML ASP ASP.NET Cache Java Visual Basic (SOAP TOOLKIT) And any other application supporting SOAP Web Service Object extends %SOAP.WebService Connect Secure Monitor Manage Authenticate XML Object Extends (%RegisteredObject, %XML.Adaptor) I/O Object Extends (%RegisteredObject)

  20. Resources: Partners Service Developer – guidelines and examples http://share.partners.org/sites/phs/sd/Pages/Home.aspx

More Related