HOPA PLUS

Implementation and using of HOPAPLUS HIS Applet allowing for spot selection among several documents

HOPA functionality, called HOPAGetSelect4ObjextEx.asp, has been implemented in HOPA API. This functionality requires HOPAPLUS license to be installed.

It allows for customizable access to possibility of graphical selection of objects and examining their properties by clicking on their spots.

This functionality can be further enhanced allowing initial choice among several documents from where final selection can be taken. It has been accomplished by generic CallHOPAGetAny4AllObject.html page, which implements multi-document choice for Any action regarded to All documents connected to given Object.

Definition of the range of documents to be presented and return information about final choice can be integrated with external Web applications.

function onAppletInit(hisApplet, customData)
{
  if (customData.Title)
    hisApplet.setActionTitle(customData.Title);
}

function onAppletAccept(hisApplet, customData)
{
  var IDValue = "";
  
  if (customData.IDField)
    IDValue = hisApplet.getPropertyValue4ObjectLinked2CurrentSpotAt
    (customData.IDField);

// proceed with calling customData.BackUrl

}

function onAppletCancel(hisApplet, customData)
{
  window.close();
}

Complex case scenario

Complex case arises when there are several documents connected to area from where parking place is to be selected. User has to choose first from which document (concerned with some sub-part of the area) the final choice would be performed.

To accomplish such goal, CallHOPAGetAny4AllObject.html page can be used in its generic or customized form. This page is designed to be embedded in HIS application and implements multi-document choice for Any action regarded to All documents connected to given Object.

It can be used in several scenarios, as described in the section called “CallHOPAGetAny4AllObject.html”. In our case, EXT site has to arrange access to regions, districts and quarters, allowing choosing final area from where parking place is to be selected; this area can have several documents connected.

HIS site delivers CallHOPAGetAny4AllObject.html page to be displayed in separate window (or in separate frame).

This page displays list of thumb-nailed pictures of relevant documents, with applet displaying first of them placed in frame beneath.

User can click another thumbnail in gallery to switch to another sub-area.

The hint displayed when cursor is over each thumbnail, can inform about sub-area description.

Further choice is performed in the same way as described in simple case.

Finally, user clicks Request reservation button.

Depending on customized part of JavaScript, original window can be closed or its frame contents can be redirected to contents delivered by target page from EXT site.

Complex case - implementation details

Subsequent parts of sample form of CallHOPAGetAny4AllObject.html call:

http://lidia.tessel.se/KBAB/Custom/CallHOPAGetAny4AllObject.html?U_F=thumb&U_A=DOCUMENT_ADD2&U_C=HOPAGetSelect4ObjectEx.asp&HN=PPLHierarchyDefinition&OC=Level_PPL_2&ID=PPL-ORN&DF=fltFreePplats&P=KBABPplats&SM=1&C_JSFile=AppletSelect.js&C_Title=Parkings%20and%20Garages%20from%20Orrholmen&C_IDField=P-platsnr%3A&C_BackUrl=http%3A%2F%2Fkate.tessel.se%2FEXT%2FAcceptPlace.html%3FSecurity%3D1234ABCD

can be explained as below (long names of parameters used for better readability):

Custom CallHOPAGetAny4AllObject.html part

http://lidia.tessel.se/KBAB/Custom/CallHOPAGetAny4AllObject.html: URL with HOPA call

?U_Form=thumb: Format of multi-document choice: thumb for thumbnail gallery, combo for drop-down box

&U_Attr=DOCUMENT_ADD2: Name of document attribute to be used as hint for thumbnail or as item on drop-down list

&U_Call=HOPAGetSelect4ObjectEx.asp: Name of target HOPA call to be called with finally chosen document connected

Standard HOPA part:

&HierName =PPLHierarchyDefinition: Name of hierarchy with parking places

&ObjClass =Level_PPL_2: Name of region object

&ID=PPL-ORN: ID of region object, from where documents are to be taken

&Present=KBABPplats: Name of presentation used

&ScaleMode=1: Recommended value of scale mode, to force Fit instead of default Match scale mode while printing

&DocFilter=fltFreePplats: The name of additional table (view) exposing DocumentID’s to be taken into account while presenting

Custom HOPAGetSelect4ObjectEx.asp part

&Custom_JSFile=AppletSelect.js: Location and name of customization script

&C_Title=Parkings%20and%20Garages%20from%20Orrholmen: Custom_Title parameter can be used to define title displayed in Applet

&C_IDField=P-platsnr%3A: Custom_IDField parameter points to desired property from selected parking as its reference

&C_BackUrl=http%3A%2F%2Fkate.tessel.se%2FEXT%2FAcceptPlace.htm%3FSecurity%3D1234ABCD: Custom_BackUrl parameter can be used to define callback call

Notes

Note that CallHOPAGetAny4AllObject.html is placed inside Custom folder which itself is not necessary but points to the fact that the page is allowed for individual customization for different applications. It has been designed so as to allow individual shaping of layout, styling and other individual features of CallHOPAGetAny4AllObject.html page according to requirements of being conformed with various external applications. Note however that such modifications may require thorough inspection of actual code and following its guidelines.

All parameters with U_* name (U stands for User, but the extended form User_* is not recognized) are parsed and consumed only by page CallHOPAGetAny4AllObject.html itself and not delivered to final HOPA call.

Allowed values for U_Form (U_F) parameter are combo for drop-down box (default), and thumb for thumbnail gallery. Other values require additional implementation in CallHOPAGetAny4AllObject.html JavaScript, following guidelines taken from existing code.

The U_Attr (U_A) parameter points to name of document attribute that should be used as hint for thumbnail or as item on drop-down list. Actual value of attribute is taken from internal call to HOPAGetDocInfo4ObjXML.asp, returning document properties. With U_Attr (U_A) parameter absent or empty, hint for thumbnail will be supressed.

In general case, value of U_Call (U_C) parameter can point to any of HOPA calls that can potentially lead to multi-document choice, like any of the following:

HOPAGetView4Object.asp
HOPAGetPrint4Object.asp
HOPAGet***4ObjectEx.asp
HOPAStartUI.asp

Default value is HOPAGetView4Object.asp. In our case, HOPAGetSelect4ObjectEx.asp will be used.

Documents to be presented can be specified further by e.g. DocCondition (DC) parameter, limiting choice e.g. only to documents of Drawing or Plan type. The DocFilter (DF) parameter can be used for additional discrimination of unneeded documents. This parameter point to the name of additional view created in HyperDoc database, which exposes e.g. only those documents, on which:

there are spots connected to parking places at all;
there are free parking places to hire.

Sample form of such view definition could be made as follows:

SELECT DISTINCT dbo.HDocSpots.Document_ID
FROM dbo.tblPplats
INNER JOIN dbo.Spot_tblPplats_Link ON
dbo.tblPplats.tblPplats_ID = dbo.Spot_tblPplats_Link.tblPplats_ID
INNER JOIN dbo.HDocSpots ON
dbo.Spot_tblPplats_Link.Spot_ID = dbo.HDocSpots.Spot_ID
WHERE (dbo.tblPplats.tblPplats_Res = 0)

Rest of custom HOPAGetSelect4ObjectEx.asp parameters is passed transparently to final HOPA call; their meaning is the same as in simple case described previously.

Advanced customization

Suppressing message about number of documents retrieved

There is the message “n documents found; m documents retrieved” at top of CallHOPAGetAny4AllObject.html page. It has been placed for presenting progress of loading subsequent documents. It can be localized within JavaScript code placed on CallHOPAGetAny4AllObject.html page. If you want to suppress this message, simply put display:none condition in style value for appropriate <DIV> tag:

<div id="DocLoad" align="center" style="width:100%;display:none"> </div>s

Suppressing unneeded attributes presented by applet

Individual code of CustAttr4HIS.xsl file placed in folder connected to virtual Config folder can be used to suppress unneeded attributes presented by applet.

Modification of shape can be done as pointed below. Sample is concerned with objects presented in KBAB database. Standard part is shown with smaller font, while necessary inserts have been presented with greater font in bold.

<?xml version="1.0" encoding="Windows-1250"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:msxsl="urn:schemas-microsoft-com:xslt"
                xmlns:tslfs="http://tessel.com/namespaces/xsl-formatting_support"
                exclude-result-prefixes="msxsl tslfs"
                version="1.0">

  <xsl:output method="xml" omit-xml-declaration="yes" />

  <xsl:template match="/">
    <xsl:apply-templates select="//HObject"/>
  </xsl:template>

  <xsl:template match="HObject">
    <xsl:variable name="obj_type" select="//ObjectType[@Name=current()/@ObjType]" />
    <xsl:variable name="hobj" select="." />
    <ObjProperties ObjType="{$obj_type/@Label}" ObjName="{@Label}" ObjID="{@ObjID}">
      <xsl:for-each select="$obj_type/ObjectField" >
        <xsl:apply-templates select="$hobj/ObjectAttr[@Name=current()/@Name]" />
      </xsl:for-each>
    </ObjProperties >
  </xsl:template>

  <xsl:template match="ObjectAttr">

    <xsl:if test="//ObjectType[@Name=current()/../@ObjType]/@Label != 'P-platsnr' or 
            @Name = 'TBLPPLATS_ID' or 
            @Name = 'TBLPPLATS_NAME' or 
            @Name = 'TBLPPLATS_ADD1' or 
            @Name = 'TBLPPLATS_RES'">

      <xsl:variable name="attr_name" select="//ObjectType[@Name=current()/../@ObjType]/ObjectField[@Name=current()/@Name]" />
      <xsl:choose>
        <xsl:when test="$attr_name">
          <Attrib AttName="{$attr_name/@Label}" FieldName="{@Name}">
            <xsl:attribute name="Value">
              <xsl:variable name="dict" select="//Dictionary[@UsedInAttr = current()/@Name]" />
              <xsl:choose>
                <xsl:when test="$dict">
                  <xsl:choose>
                    <xsl:when test="$dict/@ValFld">
                      <xsl:value-of select="$dict/DictValue/DictAttr[@Name = $dict/@KeyFld and @Value = current()/@Value]/../DictAttr[@Name = $dict/@ValFld]/@Value" />
                    </xsl:when>
                    <xsl:otherwise>
                      <xsl:value-of select="//Dictionary[@UsedInAttr = current()/@Name]/DictValue/DictAttr[@PrimaryKey = '1' and @Value = current()/@Value]/../DictAttr[not(@PrimaryKey = '1')]/@Value" />
                    </xsl:otherwise>
                  </xsl:choose>
                </xsl:when>
                <xsl:otherwise>
                  <xsl:value-of select="tslfs:FormatField(string(@Value), string(../@ObjType), string(@Name))" />
                </xsl:otherwise>
              </xsl:choose>
            </xsl:attribute>
          </Attrib>
        </xsl:when>
        <xsl:otherwise>
          <Attrib AttName="{@Name}" FieldName="{@Name}" Value="{@Value}" />
        </xsl:otherwise>
      </xsl:choose>

    </xsl:if>

  </xsl:template>

</xsl:stylesheet>

Suppressing condition does not work for objects of class different than named P-platsnr (DisplayName defined in PPLHierarchyDefinition table) and passes through only attributes from specified tblPplats table columns.

Note closing </xsl:if> that has to be added.

Note that you have to pass some identifying attribute, namely that which corresponds to Custom_IDField=Plats: value. Its value has to be accessible for retrieving among attributes delivered to applet and returned back for identification on EXT site.

Note that the same suppressing of fields filtered out will take place in standard HIS client interface.

Prefiltering objects on higher level

Introduction

In common implementation scenario, user has to choose first from which area and sub-area he/she wants to choose objects in question (e.g. parking places from districts and quarters). The list of administrative units to be presented has to be completed and presented on EXT site.

In simplest case, such list can be static, following administrative structure assumed in given hierarchy and corresponding to the same structure formed in HyperDoc database.

In more advanced implementation, however, it is advised to build such list in dynamical way, based on data taken from EXT administrative server (native to EXT site) or taken from HyperDoc data, i.e. from HIS site (external to EXT site). Such implementation will allow for automatic following any changes in administrative structure.

The second solution will be discussed in more detailed fashion, because it allows handling additional natural requirement – to present only those administrative units where feasible objects to be chosen do exist, e.g. free parking places. It has no sense to present areas with no free parking places at all.

Database modifications

To accomplish this goal, additional modifications has to be done in HyperDoc database to allow for revealing property of areas of having accessible objects for choice. This modification will be described using KBAB database used in Parking and Garage Renting application as an example.

It has been proposed to do so in similar way as modification done regarding object of parking place itself. Its original table tblPplats has been renamed to tblPplats0, while tblPplats view has been defined in the same time with additional expression calculating value of “Reserverat:” field, based on reservation dates kept in other columns:

SELECT     [dbo].[tblPplats0].*, [tblPplats_Res] = CASE WHEN ([dbo].[tblPplats0].[tblPplats_Add7] IS NULL) OR
                      ([dbo].[tblPplats0].[tblPplats_Add8] <= getdate()) THEN 0 ELSE 1 END
FROM         [dbo].[tblPplats0]

Additional columns tblPplats_Res is presented as “Reserverat:” field because it has been added to HDocObjectFields table:

ObjectClass	Sequence	FieldName	LabelText
tblPplats	9	tblPplats_Res	Reserverat:

The table Level_PPL_2 has been renamed to Level_PPL_2_0, and the view Level_PPL_2 has been defined as follows:

SELECT dbo.Level_PPL_2_0.*, 
SUM(1 - dbo.tblPplats.tblPplats_Res) AS Level_PPL_2_Fri

FROM dbo.Level_PPL_2_0 

INNER JOIN dbo.tblPplats ON 
dbo.Level_PPL_2_0.Level_PPL_2_ID = dbo.tblPplats.Level_PPL_2_ID

GROUP BY dbo.Level_PPL_2_0.Level_PPL_1_ID, 
dbo.Level_PPL_2_0.Level_PPL_2_ID, 
dbo.Level_PPL_2_0.Level_PPL_2_Name, 
dbo.Level_PPL_2_0.Level_PPL_2_Description, 
dbo.Level_PPL_2_0.Level_2_Area, 
dbo.Level_PPL_2_0.Level_2_Add1, 
dbo.Level_PPL_2_0.Level_2_Add2, 
dbo.Level_PPL_2_0.Level_2_Add3, 
dbo.Level_PPL_2_0.Level_2_Add4, 
dbo.Level_PPL_2_0.Level_2_Add5, 
dbo.Level_PPL_2_0.Table_Name

The argument for SUM function is equal to 1 when parking place is free, so the total value for given Stadsdel is number of free parking places in this subarea.>

SELECT dbo.Level_PPL_1_0.*, 
SUM(dbo.Level_PPL_2.Level_PPL_2_Fri) AS Level_PPL_1_Fri

FROM dbo.Level_PPL_1_0 

INNER JOIN dbo.Level_PPL_2 ON 
dbo.Level_PPL_1_0.Level_PPL_1_ID = dbo.Level_PPL_2.Level_PPL_1_ID

GROUP BY dbo.Level_PPL_1_0.Level_PPL_1_ID, 
dbo.Level_PPL_1_0.Level_PPL_1_Name, 
dbo.Level_PPL_1_0.Level_PPL_1_Description, 
dbo.Level_PPL_1_0.Level_1_Area, 
dbo.Level_PPL_1_0.Level_1_Add1, 
dbo.Level_PPL_1_0.Level_1_Add2, 
dbo.Level_PPL_1_0.Level_1_Add3, 
dbo.Level_PPL_1_0.Level_1_Add4, 
dbo.Level_PPL_1_0.Level_1_Add5, 
dbo.Level_PPL_1_0.Table_Name

The argument for SUM has been taken from lower level area, so the total value for given Område is number of free parking places in this area, taken from all its subareas.

Note that it is necessary to list each column of Level_PPL_2_0 and appropriately Level_PPL_1_0 table in corresponding GROUP BY clause. In case of any changes in table structure, this list has to be updated.

In databases where administrative objects are already represented by views, it is sufficient to add appropriate column to view definition.

To complete such modification, appropriate labels have to be defined in HDocObjectFields as follows:

ObjectClass	Sequence	FieldName	LabelText
Level_PPL_1	4	Level_PPL_1_Fri	Ledig:
Level_PPL_2	4	Level_PPL_2_Fri	Ledig:

As additional bonus, total number of free parking places can be presented as additional information in HyperDoc database:

Areas with all parking places reserved (or with no parking places at all) are reported as having 0 free places:

Finding areas of different level with free parking places only

It is possible to obtain list of all Level_PPL_1 “Område” areas with non-zero number of free parking places using following HOPAFindObjectsXML call with XML query passed as string in URL query parameter (new lines added for better readability):

http://localhost/KBAB/HOPAFindObjectsXml.asp?query=<Query HierName='PPLHierarchyDefinition'><FindObjects ObjectType='LEVEL_PPL_1'><Criterion Field='LEVEL_PPL_1_Fri' MatchMode='10' Condition='0'/></FindObjects></Query>

See HOPA help manual for detailed explanation of query parameters.

The response will be as follows:

<?xml version="1.0" encoding="UTF-8"?>
<QueryResults>
  <HObject Class="LEVEL_PPL_1" ObjID="PPLHierarchyDefinition|1|Level_PPL_1|PPL-CET">
    <ObjectAttr Name="LEVEL_PPL_1_ID" Value="PPL-CET"/>
  </HObject>
  <HObject Class="LEVEL_PPL_1" ObjID="PPLHierarchyDefinition|1|Level_PPL_1|PPL-OSR">
    <ObjectAttr Name="LEVEL_PPL_1_ID" Value="PPL-OSR"/>
  </HObject>
  <HObject Class="LEVEL_PPL_1" ObjID="PPLHierarchyDefinition|1|Level_PPL_1|PPL-VAR">
    <ObjectAttr Name="LEVEL_PPL_1_ID" Value="PPL-VAR"/>
  </HObject>
</QueryResults>

It is possible to obtain list of all Level_PPL_2 “Stadsdel” areas with non-zero number of free parking places using following HOPAFindObjectsXML call with XML query passed as string in URL query parameter (new lines added for better readability):

http://localhost/KBAB/HOPAFindObjectsXml.asp?
query=
<Query HierName='PPLHierarchyDefinition'>
  <FindObjects ObjectType='LEVEL_PPL_2'>
    <Criterion Field='LEVEL_PPL_2_Fri' MatchMode='10' Condition='0'/>
  </FindObjects>
</Query>

See HOPA help manual for detailed explanation of query details.

The response will present ALL “Stadsdel” areas from all “Område” areas at once:

<?xml version="1.0" encoding="UTF-8"?>
<QueryResults>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-CEM">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-CEM"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-HEN">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-HEN"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-KVT">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-KVT"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-NOD">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-NOD"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-ORN">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-ORN"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-VIN">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-VIN"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-FAD">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-FAD"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-KRN">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-KRN"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-BEE">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-BEE"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-GRN">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-GRN"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-VAS">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-VAS"/>
  </HObject>
</QueryResults>

Note that the PPL-SKE Stadsdel has been skipped in the response because it has no free parking places.

If it has been decided to present target client only one level of area hierarchy, to simplify his/her choice, it is possible to use only one of the above calls according to design decisions.

All Stadsdel areas can be presented at once, limited only to those which have free parking places. Documents with spots linked to parking places have to be connected to Stadsdel objects. It leads to lower number of documents in each area of greater number to choose from.

Alternatively, only higher level Område areas can be listed for choice, but all documents have to be linked additionally to Område objects in HyperDoc database. It leads to greater number of documents in each area of lower number to choose from.

Sometimes, such designs in small databases can be satisfactory. However, we will discuss more general case when we want to present two-level choice of areas, allowing for faster choice among areas (with two-click interface) and lower number of potential documents for each subarea.

First list of Område areas can be built from first call as above. For each Område area chosen, next list can be dynamically built using more specific shape of HOPAFindObjectsXML call as follows:

http://localhost/KBAB/HOPAFindObjectsXml.asp?
query=
<Query HierName='PPLHierarchyDefinition' 
SubtreeParentObjID='PPLHierarchyDefinition|1|Level_PPL_1|PPL-VAR'>
  <FindObjects ObjectType='LEVEL_PPL_2'>
    <Criterion Field='LEVEL_PPL_2_Fri' MatchMode='10' Condition='0'/>
  </FindObjects>
  </Query>

The SubtreeParentObjID parameter points to the sample value of ObjID parameter equal to PPLHierarchyDefinition|1|Level_PPL_1|PPL-VAR taken from previous response (marked in yellow here and above). It allows for searching among only children of pointed object. (It is not documented in HOPA manual).

The response will present ALL “Stadsdel” areas from given “Område” area:

<?xml version="1.0" encoding="UTF-8"?>
<QueryResults>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-BEE">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-BEE"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-GRN">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-GRN"/>
  </HObject>
  <HObject Class="LEVEL_PPL_2" ObjID="PPLHierarchyDefinition|1|Level_PPL_2|PPL-VAS">
    <ObjectAttr Name="LEVEL_PPL_2_ID" Value="PPL-VAS"/>
  </HObject>
</QueryResults>

Note that the PPL-SKE Stadsdel has been skipped in the response again because it has no free parking places.

Unfortunately, the information about Område and Stadsdel areas passed in query results has no descriptive meaning and can be used for referencing purposes only. To present list of areas meaningful to the user, their names and maybe other properties (number of free parking places, for example!), together with e.g. picture or plan connected to given area for illustration purposes, have to be extracted from HyperDoc databases using additional HOPA calls for each area in question. Combined information can be grouped in appropriate HTML layout using e.g. combo boxes (<SELECT> tags with <OPTION> items) created dynamically on the fly, with text for each item taken from area name and value taken from area ID.

It is not the subject of current documentation to provide final solutions for implementing and organizing such advanced layout, so the simplest steps will be presented leading to skeleton of functioning example.

There are three possible architecture arrangements leading to target solution.

In first arrangement, page implementing area and subarea choice is installed on HIS site, as kind of customized add-in. It can then use XML transfer of HOPA responses using internal XmlHTTP protocol. The XML document obtained on HIS client side can be parsed with JavaScript and used to build e.g. appropriate <SELECT> tags presenting list of choice.

This page has to be called from EXT site and displayed in separate window spawned from EXT main window or in frame arranged within EXT hosting page. Final choice of lowest-level subarea has to be passed finally to CallHOPAGetAny4AllObject.html page, together with e.g. C_BackUrl parameter to be used to close registration request.

In second arrangement, page implementing area and subarea choice is installed on EXT site, where it can use all styling environment used in hosting page. However, cross-site transfer of XML documents is not allowed in this case as a result of sandbox security, so other mechanisms have to be used to close implementation.

All HOPA calls returning XML documents can be modified by adding additional CF (ClientFunc) parameter to URL query. Value of this parameter should represent name of existing JavaScript function, implemented on EXT page. The whole response of such HOPA call should be used to build dynamically <SCRIPT> tag inserted below <HEAD> tag of hosting EXT page, which contents will become a call to this function, with parameter containing passed data presented in JSON format. After inserting, the “ClientFunc” function will be immediately called by browser mechanism, and data passed to it can be used for dynamical building of list of choice and its elements.

To illustrate this, sample format of HOPA call can be formulated as follows:

http://localhost/KBAB/HOPAFindObjectsXml.asp?
query=
<Query HierName='PPLHierarchyDefinition'>
  <FindObjects ObjectType='LEVEL_PPL_1'>
    <Criterion Field='LEVEL_PPL_1_Fri' MatchMode='10' Condition='0'/>
  </FindObjects>
</Query>&
ClientFunc=Level_PPL_1_List

The response will be as follows:

Level_PPL_1_List(
{ "QueryResults": 
  { "HObject": 
    [ 
      { "Class": "LEVEL_PPL_1",  
        "ObjID": "PPLHierarchyDefinition|1|Level_PPL_1|PPL-CET", 
        "ObjectAttr": 
        { "Name": "LEVEL_PPL_1_ID",  
          "Value": "PPL-CET" 
        } 
      }, 
      { "Class": "LEVEL_PPL_1",  
        "ObjID": "PPLHierarchyDefinition|1|Level_PPL_1|PPL-OSR", 
        "ObjectAttr": 
        { "Name": "LEVEL_PPL_1_ID",  
          "Value": "PPL-OSR" 
        } 
      }, 
      { "Class": "LEVEL_PPL_1",  
        "ObjID": "PPLHierarchyDefinition|1|Level_PPL_1|PPL-VAR", 
        "ObjectAttr": 
        { "Name": "LEVEL_PPL_1_ID",  
          "Value": "PPL-VAR" 
        } 
      } 
    ] 
  }
}
);

The JSON syntax allows for easy access to passed data using natural JavaScript object notation.

In third arrangement, page presenting area and sub area choice is generated from server pages on EXT site. In this solution, server page on EXT site uses inteserver XmlHTTP transfer to communicate with HOPA interface. Obtained XML response can be easily converted via XSLT transformation made on EXT server to HTML snippets presenting list of links or combo boxes with options allowing choice of area and sub area among all found by HOPA queries. This solution is to be developed totally on EXT side, using any server technology (ASP, ASPX, PHP or other) used to implement EXT application.

All solutions have their pros and cons. Access to JSON data from JavaScript is simpler, however infrastructure of data passed as code snippet fragments is more advanced, or some predefined frameworks can be used for it. On the other side, direct XML transfer is more natural, bur makes a division between EXT part and HIS part, which may result in differences in layout and styling. Finally, EXT server side solution could be more elegant and robust, but detailed implementation depends on EXT server technology used.

Prev	Up	Next
	Home