Copyright © Cloud Software Group, Inc. All Rights Reserved

Launching a Custom WCC Application

When a WCC application is created in General Interface Builder, a launch fragment is created that is used to launch your custom application. This launch fragment is located as follows:

WorkspaceDir\WCCProjectName.html

where WorkspaceDir is the workspace directory you specified after starting General Interface Builder, and WCCProjectName is the name you gave the WCC project when creating your custom application in General Interface Builder.

For example, if you create a custom application called “Accounts”, an Accounts.html file is created in your workspace directory. Executing this file starts the custom application.

To launch a WCC application that has been deployed to a Web server, point a browser at the application’s launch fragment, as follows:

http://Host:Port/ClientDir/WCCProjectName.html

where:

−	Host is the machine name on which the application and Action Processor are being hosted.

−	Port is the port number used by the Web server to communicate with web applications.

−	ClientDir is the directory (or virtual directory alias) in which you deployed the WCC application files.

−	WCCProjectName is the name you gave the WCC project when creating your custom application in General Interface Builder

For example:

http://Roxie:8090/AccountProject/Accounts.html

Cross-Domain Scripting

Cross-domain scripting is a security vulnerability of web applications. If you trigger cross-domain scripting, and your browser doesn’t allow it, the web application will not run (in the case of a WCC application, it will state that it is unable to establish a connection to the Action Processor).

Some browsers are more strict about enforcing cross-domain scripting than others; and newer versions of browsers tend to be more strict than older versions. Some browsers also provide methods to allow cross-domain scripting—see your browser’s documentation for more information.

Cross-domain scripting affects accessing WCC applications in the following ways:

•

URL used to launch the application - To prevent cross-domain scripting, it is best practice to ensure that the domain portion of the URL that is entered into the address line of the browser exactly matches the domain portion of the Action Processor URL specified in the application’s config.xml file.

The domain consists of the "http://Host:Port" part of the URL.

The domain used to launch the application cannot differ in any way from the Action Processor’s specified domain, otherwise cross-domain scripting may be triggered (depending on your browser). That is, you cannot use "http" in one and "https" in the other; you cannot use a host name in one and an IP address in the other; one host name cannot be unqualified and the other qualified; you cannot use "localhost" in one and "127.0.0.1" in the other.

To determine if cross-domain scripting is being used, the browser simply compares the URL domains as strings.

•	Running the application from the local file system - Because of the security risk of cross-domain scripting, some browsers will not allow you to run a web application (including a WCC application) from the local file system.

Note that you would typically only run a WCC application from the file system in a testing and development environment. In a production environment, it is expected that the application will be deployed to a Web server and run from there. For information about deploying, see Deploying Your Custom Application.

Starting Multiple Applications from the Launch Fragment

You can modify the launch fragment to specify that multiple applications load when the file is executed. It allows you to specify a separate <div /> element for each application so that each one is displayed in its own area on the screen.

The following provides an example of how you could create two WCC applications, launch them both from a single launch fragment, and have them interact by one application subscribing to the events of the other.

This somewhat simulates a portal environment, except that this example loads two applications within one container, rather than each application being launched within a separate portal. However, you can use this information to help you set up your portal environment.

Assumptions: We will create two applications: Accounts and AccountDetail. Accounts will display a Login dialog; it will then display the work queue list when the user logs in. AccountDetail will subscribe to the single-click event of the UserWorkQs component in the Accounts application, causing the work item list to display in a separate area in the container when the user clicks on a work queue in the work queue list displayed by Accounts.

1.	Create and save Accounts, which should contain two components: Login and UserWorkQs. The UserWorkQs component needs to subscribe to the LoginComplete event on the Login component.

For information about how to create a custom application using components, see Tutorial.

2.	With Accounts open in General Interface Builder, create an event definition file for Accounts that AccountDetail can import so that it can subscribe to events published by components in Accounts.

For information about creating an event definition file, see Events From External Applications.

3.	Create the AccountDetail application, which should contain one component: WorkItems.

4.	With AccountDetail open in General Interface Builder, display the Events Editor.

Note that at this point, there are no events to which the WorkItems component can subscribe because it is the only component in the application.

5.	In the Events Editor, click the Import button.

6.	On the Import Files dialog, navigate to and select the event definition file that you created in step 2, then click Import.

Event definition files are saved in the \defs folder under the application from which you created it, with the name WCCProjectName.app.pub.xml. For example:

   WorkspaceDir\JSXAPPS\Accounts\defs\Accounts.app.pub.xml

The Events Editor should now include all of the events from Accounts.

7.	Subscribe to the List Item Select (single click) event on the WorkQs component.

8.	Save AccountDetail.

At this point, we have created two separate applications, and they each have their own launch fragment that starts the individual application. We will now create a launch fragment that will start both applications and display each in its own region on the screen.

9.	Make a copy of the launch fragment created for Accounts and save it with whatever name you desire. (The launch fragment for the Accounts application is saved in the WorkspaceDir directory, as file Accounts.html.)

10.	Modify the new launch fragment as follows:

a.	Change the value of window.wccAppCount to 2, which is the number of applications that will be loaded by this launch fragment.

b.	Uncomment the <div /> that is located near the bottom of the file.

c.	In the <div /> that you uncommented, replace the application name with the name of your second application (AccountDetail in this example). It should now appear as follows:

Now we need to specify how much of the screen each of the applications will consume — currently, the Accounts application is set to use 100% of the screen.

d.	Copy the style attribute from the <div /> element that pertains to the first application, then paste it into the <div /> element that pertains to the second application, replacing the “. . .” placeholder.

e.	In the <div /> element for the first application, change the height value in the style attribute to 30%. This causes the first application to consume 30% of the container.

f.	In the <div /> element for the second application, change the top value in the style attribute to 30%, and the height value in the style attribute to 70%. This causes the second application to start at 30% from the top, and consume 70% of the container.

The new launch fragment should now look as follows (with comments removed for brevity):

11.	Save the new launch fragment, then execute it.

The Login dialog is displayed. When a valid user name and password are entered, the work queue list is displayed in the top 30% of the screen. When a work queue is selected, the work item list is displayed in the bottom 70% of the screen.

Multiple Applications Referencing a Single Configuration File

When modifying the launch fragment to launch multiple WCC applications, you can also specify that more than one application use the same config.xml configuration file. To do this, set the jsxapppath attribute in the launch fragment to point to the directory that contains the config.xml file you want the launch fragment to reference.

It may be beneficial to configure a single base-level WCC application that can then be used by several WCC applications without the need to repeat the same common files in separate project directories.

By setting the jsxapppath to this single base-level WCC application path, each application is launching from that path, sharing the config.xml file and potentially any other files (class files, GUI component files, etc.) that may have common use across several WCC applications.

In the example above, the first application is currently using the config.xml file in the JSXAPPS/Accounts directory; the second application is using the config.xml file in the JSXAPPS/AccountDetail directory.

You can have both applications use the same config.xml by setting both jsxapppath attributes to point to the same directory.

Also note that if multiple applications are using the same jsxapppath, they also share the same userAccessProfiles.xml located in that path.

Multiple applications cannot share the same wccConfig.xml file (see WCC Configuration File). Each wccapppath attribute in the launch fragment must point to the directory containing the wccConfig.xml for each WCC application.

Launching a WCC Application in an HTML Frame

To be able to launch a custom WCC application in an HTML frame (for example, an iframe in a portal), you must make some modifications to the launch fragment for the application.

Prior to launching the application in a frame:

1.	Open the launch fragment.

2.	Locate the following: “NOTE: To allow display of this application under frames remove the following style and script elements”.

3.	Remove (or comment out) the <style> and <script> elements immediately after the note. For example:

---

---

 

4.	Locate the following: “NOTE: To allow display of this application under frames remove the next script element”.

5.	Remove (or comment out) the <script> element immediately after the note (do not, however, remove the second <script> element following the note). For example:

---

---

 

6.	Save and close the launch script.

Copyright © Cloud Software Group, Inc. All Rights Reserved