infoEngineUserGuide_note

Info*Engine tasks are always stored as text documents within the Info*Engine task
root. There are several ways to execute tasks, including the following:
An external Simple Object Access Protocol (SOAP) request.

Some of the Info*Engine tags can execute webjects that extract data
from enterprise systems through an adapter

When a task is contained in its own document, it is called a standalone task.

Queuing a task for execution. After you queue a task, you can disconnect
from your application. Any results are queued for later retrieval either by
you or others. By queuing a task, you can also guarantee that the task is
completed, even if it is interrupted due to a system problem.

In addition, requests can come from
SOAP requests that come from third-party applications through the Info*Engine
SOAP servlets.

Adapters provide a connection between the Info*Engine server and information
systems. One side of the adapter communicates with the Info*Engine server and
the other side communicates with the information system. The adapter translates
Info*Engine server requests into information system requests.

Info*Engine standalone tasks are XML-based documents that provide you with a
way to control the retrieval and manipulation of data outside of your JSP pages or
application.

Query webjects search external databases for objects that match specified
criteria. Each adapter supports a unique set of query webjects because the
adapter must handle queries differently due to the nature of the underlying
data repositories.
When Info*Engine encounters a query webject, it passes the webject to the
appropriate adapter. The adapter then performs the specified query. The group
of objects returned by a successful query is stored by Info*Engine. Thus,
making the results available to other webjects. For more information, see
Task Webject Reference on page 355.

For advanced users, Info*Engine also provides methods such as setOutputStream,
setInputStream, and sendContent that can manipulate BLOBs and the Java
language provides classes such as java.io.ByteArrayInputStream and
java.io.ByteArrayOutputStream to read or write BLOBs to or from
memory.

<h2>Upload File to Oracle BLOB Column</h2>
<form method="POST" action="/Windchill/servlet/IE/tasks/com/company/UploadBlob.xml"
enctype="multipart/form-data">

The UploadBlob.xml task identified in the action attribute of the form element
is the task that the Info*Engine server executes. This task (which is described in
the next section) uses the form variables to identify the adapter instance and specify
the name that corresponds to the BLOB in the table row where the BLOB is stored.

<form method="POST" action="/Windchill/servlet/IE/tasks/com/company/DownloadBlob.xml" enctype="multipart/form-data">

The following actions are allowed in this example application:
• Query—Search a given repository for parts.
• Fetch—Fetch a single part from a given repository.
• Download—Download the primary content of a part.
This example can be located in your Windchill installation at:
This example can be located in your Windchill installation at:
<Windchill>/prog_examples/federation/search_portal

Info*Engine provides a directory structure under which you should save your
task files.
Windchill is configured to look for Info*Engine tasks within the
<Windchill>/tasks directory.

Entering a task URL in the web browser is an easy way to execute the task without
providing the additional coding required to execute the task through an application
or JSP page.
Therefore, to execute the com/company/CreateGroup.xml task using
the myServer host name and the Windchill application URL, specify the
following URL:
http://myServer/Windchill/servlet/IE/tasks/com/company/CreateGroup.xml

The following rules apply to credentials mapping:
• If the author of a task or JSP page explicitly specifies DBUSER and PASSWD
parameters on a webject, those parameters take precedence over any other
authentication information that might be available.
• If DBUSER and PASSWD parameters are not explicitly specified, Info*Engine
attempts to provide values for them from the credentials mapping information.

Windchill is pre-configured to include a credentials mapping task.
This task is configured through the Windchill adapter using the
wt.federation.task.mapCredentials property value, which is set
to /wt/federation/MapCredentials.xml. The contents of this task
are dynamically generated, starting with the following file:
<Windchill>/tasks/wt/federation/
MapCredentials.xml.template
using the property values found in site.xconf.
Windchill’s LDAP access for user and group information relies on this
credentials mapping task, and can provide credentials to adapters based on
whether the current user is an administrator or a regular user. If you would like
to modify mapped credentials, you can set properties in site.xconf

If you need to customize this task you should do so by modifying the
MapCredentials.xml.template file. You should also keep a
backup copy, because patch or maintenance release installation may
overwrite your customization.

Using the xconfmanager utility, you can commands similar to the following to set
these properties:
xconfmanager -p -s "mapcredentials.admin.adapters=<adapter name>^
<privileged User>^<privileged
To set credentials for a Windchill administrator, use the following command:
mapcredentials.admin.adapters=<unique name of the adapter>^<username>^<password>
To set credentials for a user without Windchill administration privileges, use the
following command:
mapcredentials.nonprivileged.adapters=<unique name of the adapter>^<username>^<password>

Windchill offers a toolset that facilitates deployment of the same Info*Engine-based
web service that leverages JAX-WS (Java API for XML Web Services) in order
to handle the SOAP/XML and security-related web service details. This toolset
is available in addition to the Info*Engine-based web services that are supplied
by the SimpleTaskDispatcher servlet.

Aside from leveraging JAX-WS for the SOAP-related details, a major advantage
to using this framework is the addition of configurable and efficient security.

Legacy Info*Engine web services rely solely upon web server authentication
for security. This means that SOAP clients must have complete access to
user credentials, and must supply those credentials to the web server per its
authentication requirements (typically HTTP Basic Authentication). However, this
presents a fairly significant roadblock to developing applications that implement
SSO (Single Sign On).

With web service security support in Windchill, you can establish a trust
relationship between an application (such as a portal server) and an Info*Engine
web service by exchanging public key information, requiring that SOAP message
exchanges be properly signed and encrypted, and requiring that they contain a
valid username token that the web service should trust. As long as the incoming
SOAP message meets the security requirements and can be decrypted using a
public key found in the server’s truststore, the web service then executes a request
that has been authenticated with the username.

The supplied tooling is enabled using Apache Ant, located in:
<Windchill>/ant
(where <Windchill> is the Info*Engine installation directory).
The tooling is intended to be run from a windchill shell, in which case the ant
command is already in your path.

The directory that contains the Apache Ant build tools for deploying a web service
is located in <Windchill>/bin/adminTools/WebServices and contains
the following:
• build.xml
The primary Apache Ant build script used to deploy web services and associate
those services with security policies.
• security.properties
A properties file containing the security-related configuration information
used when deploying a web service. This file contains the security policy to
use, the server-side truststore and keystore configurations, and any additional
policy-specific configuration (if necessary) that is to be used at deployment
time.

This shared, symmetric key is generated at runtime and
encrypted using the service’s certificate. The client must specify the alias in the
truststore by identifying the server’s certificate alias.

The server security.properties file is found at:
<Windchill>/bin/adminTools/WebServices/security.properties

If you want to undeploy your web service from your installation, simply run the
undeploy target for the src/build.xml script of your project. For example:
% cd <Windchill>/prog_examples/MyProject/src
% ant undeploy
The undeploy target completes the following actions:
• Removes the servlet configuration from web.xml
• Removes the web service configuration from sun-jaxws.xml
• Removes the security policy configuration file
• Removes the JAR file supporting your web service
• Uninstalls the Info*Engine tasks (if your service is based on Info*Engine tasks)

Using Security Policies
When securing a web service with one of the supported security policies (other
than web server authentication), a Java client needs access to its own keystore and
truststore. Paths to these files (keystore and truststore) are configured for use by
the build framework in the following:
<Windchill>/bin/adminTools/WebServices/client/security.properties