Skip Headers
Agile Product Lifecycle Management AIS Developer Guide
Release 9.3.3
E39309-02
  Go To Table Of Contents
Contents
Previous
Previous 		 Next
Next		  

1 Introduction

This chapter includes:

1.1 Understanding AIS

The Agile Integration Services (AIS) are a collection of predefined Web Services in the Agile Integration Framework that enable communication between the Agile Application Server and disparate systems including:

  • Enterprise Resource Planning (ERP) systems

  • Customer Resource Management (CRM) systems

  • Business-to-Business Integration systems (B2B)

  • Other Agile PLM systems and supply chain partners

Using AIS to exchange content with other systems simplifies the process for aggregating unprocessed product content, and makes critical product content available in real time to other systems. AIS Web Services also provide import and export capabilities that you can use to:

  • Make product content available to Enterprise Application Integration (EAI) systems

  • Share product content with product design, manufacturing planning, shop floor, and ERP and CRM applications

  • Make product content available to B2B systems that can transfer Agile Application Server data across corporate boundaries to external applications

  • Provide content to custom applications

  • Import product content data from ERP and other supply-chain applications

1.1.1 Key Features

Key features supported by AIS include:

  • Programmatic access to data -- AIS supports programmatic access to data stored in Agile PLM systems.

  • Programmatic validation of imported data-- Using the Agile SDK methods, AIS enables checking the imported data for compliance with server rules before they are actually imported.

  • Product content accessibility -- AIS provides accessibility to Agile product content outside of corporate firewalls using standard HTTP(S) technology.

  • Apache Axis support -- Agile Web Service Extensions (WSX) are based on the Apache eXtensible Interaction System (Axis) packages and Agile certifies client applications that use the Axis package client.


Note:

Export and Import attachment types are not compatible with the .Net attachment types.

  • Multiple output format support -- AIS supports the aXML and Product Data eXchange (PDX) 1.0 formats (PDX is defined in Web Services Operations).

  • Internet Security safeguards -- AIS communicates with XML-compliant applications using Internet-standard communication and security protocols (HTTP and SSL), for a secure and firewall-friendly interface.

  • Multilevel BOM support -- AIS supports converting a multilevel BOM into individual parts data in the XML format.

1.1.2 AIS Architecture

Connection to AIS is established using standard Web service invocation methodologies shown in the following illustration.

1.1.2.1 AIS Folders

AIS documentation and source files for sample clients are in the AIS_samples.zip folder. You can find this folder in Oracle Oracle Technology Network at: http://www.oracle.com/technetwork/indexes/samplecode/agileplm-sample-520945.html. For more information, contact your System Administrator, or refer to your Agile PLM installation Guide.

The AIS_samples.zip file includes the following folders:

  • documentation - Documents the Web Services that are supported by the Agile Import/Export APIs.

  • lib - Contains the common JAR files used by AIS samples.

  • sample - Contains the source code of a sample Import/Export Web service client.

1.2 Understanding AIS Web Services

AIS Web Services is a technology for building distributed applications. These services, which are available over the Internet, use a standardized XML messaging system and are not tied to any one operating system or programming language. Through Web Services, you can encapsulate existing business processes, publish them as services, search for and subscribe to other services, and exchange information throughout and beyond the enterprise. Web Services are based on universally agreed upon specifications for structured data exchange, messaging, discovery of services, interface description, and business process design.

A Web service makes remote procedure calls (RPC) across the Internet. It uses:

  • HTTP(S) or other transport protocols such as HTTP to transport requests and responses.

  • Simple Object Access Protocol (SOAP) to communicate the request and response information.

The key benefits of Web Services are:

  • Service-oriented Architecture (SOA) -- Unlike packaged products, Web Services can be delivered as streams of services that allow access from any platform. SOAs are a new approach to enterprise application integration by building applications from software services.

  • Interoperability -- Web Services ensure complete interoperability between systems.

  • Integration -- Web Services facilitate flexible integration solutions, particularly if you are connecting applications running on different platforms or written in different languages.

  • Modularity -- Web Services offer a modular approach to programming. Each business function in an application can be exposed as a separate Web service. Smaller modules reduce errors and result in more reusable components.

  • Accessibility -- Business services can be completely decentralized. They can be distributed over the Internet and accessed by a wide variety of communications devices.

  • Efficiency -- Web Services constructed from applications meant for internal use can be used externally without changing code. Incremental development using Web Services is relatively simple because Web Services are declared and implemented in a human readable format.

Web Services have certain limitations of the technology as it exists today, for example, supported software and specifications, problems using certain versions of applications or tools. In view of these constraints, consider the following when developing Web service applications:

  • When developing Web service applications, avoid advanced operations such as distributed garbage collection, object activation, or call by reference. SOAP as a simple mechanism for handling data and requests over a transport medium is not designed to handle these operations.

  • Web Services are network-based and are therefore affected by network traffic. The latency for any Web service invocation can often be measured in hundreds of milliseconds. Thus, the extent of functionality provided by the service must be significant enough to warrant making a high-latency call.

  • Web Services do not work well with conversational programming languages. Thus, when designing services that you want to expose, make the service as independent as possible from these development tools.

1.2.1 Web Services Architecture

Web services architecture is best defined in terms of its roles and protocol stack:

  • Web service roles:

    • Service provider - The provider of the service by Implementing and making it available on the Internet.

    • Service requester - The user of the service who accesses the service by opening a network connection and sending an XML request.

    • Service registry - This is a centralized directory of services where developers can publish new services or find existing ones.

  • Web service protocol stack:

    • Service transport layer - Uses HTTP to transport messages between applications. Other transports will be supported in future AIS releases.

    • XML messaging layer - Encodes messages in XML format by using SOAP, a platform-independent XML protocol used to exchange information between computers. It defines an envelope specification for encapsulated data being transferred, the data encoding rules, and remote procedure call (RPC) conventions.

    • Service description layer - Describes the public interface to a specific Web service by using the Web Service Description Language (WSDL) protocol.

  • WSDL defines an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages, which contain either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a network protocol and message format.

  • WSDL allows description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.

  • A WSDL document defines services as collections of network endpoints (called ports). A port is defined by associating a network address with a reusable binding. A collection of ports defines a service.

    • Service discovery layer - Centralizes services into a common registry by using the Universal Description, Discovery, and Integration (UDDI) protocol.


Note:

AIS Web services do not currently support UDDI or other service discovery layers.

1.3 Web Services Operations

AIS enable you to export data programmatically into structured XML documents and import data into the Agile PLM system with the following prebuilt Web service operations:

  • exportData -- A Web service operation that extracts data from an Agile PLM system. The exportDataRequest element encapsulates all the information needed to extract data from an Agile PLM system. The ExportData Web service operation supports the following formats:

    • Product Data eXchange (PDX) -- A standardized XML format for representing structured product content. It provides a means for partners in the e-supply chain (OEMs, EMS providers, and component suppliers) to exchange product content and changes (BOMs, AMLs, ECRs, ECOs).

For more information about PDX, including a link to DTD, visit http://webstds.ipc.org/2571/2571.htmhttp://webstds.ipc.org/2571/2571.htm.

  • Agile XML (also known as aXML) -- Agile XML format is an XML representation of Agile's business schema. The aXML file contains all product content managed in Agile such as items, change details, manufacturer information, cost, drawings and other files. As a representation of schema elements across all Agile products, aXML will evolve with Agile's business schema over time.

The list and location of Agile aXML schema files for different releases of the application are available at the following sites:

  • exportPartList -- A Web service operation that takes a multilevel BOM and "flattens" it into a list of the items and associated manufacturer parts, and their quantities in the BOM; it then returns the data in aXML format. That is, it enables you to extract a rolled up set of parts, and the related Quantities Per Top Level Assembly (QPTLA). The exportPartlistRequest element encapsulates all the information needed to extract a flattened partlist from an Agile PLM system.


Note:

The value of the QPTLA is computed as the sum over recursive products starting from the top of the BOM tree. exportPartlist calculates the QPTLA for each unique item-revision pair, and returns the results in the Part Quantities element of the resulting aXML output.

  • importData -- A Web service operation that imports data into the Agile PLM system. The importDataRequest element encapsulates all the information needed to request an import operation. The source for the import data can be an Agile database, a third party Product Data Management (PDM) system, or an Enterprise Resource Planning (ERP) system. The Agile server stores information about customer-specific items. It also maintains the relationships that assembly parts have with BOM components and that parent items have with approved manufacturers.

  • importSupplierResponse -- A Web service operation that imports an RFQ response from a supplier. The response is associated with an existing RFQ in the Agile PLM system.


Note:

The importSupplierResponse Web service operation is deprecated and may not be supported in future releases. Use importData instead. For more information, see "Importing Supplier Responses".

These Web service operations are invoked by submitting a properly formatted XML document to AIS. The contents of the XML document define the parameters that determine how the operation should be performed. For more information about using the prebuilt AIS Web Services, see Chapter 2, "Using AIS Web Services."

1.4 Web Services Extensions

You can use the Agile SDK to develop Web service extensions (WSX) that leverage the functionality of AIS while extending the functionality of the Agile PLM system. For example, if you need to extract data from the Agile server and then transform it before sending it to another ERP system, you could create a custom Web service that leverages the Export web service. For more information about web service extensions, refer to the Agile SDK Developer Guide.

1.5 Security Considerations

AIS communicates with XML-compliant applications using Internet-standard communication and security protocols (HTTP and SSL). Communication between AIS and its clients (via the Web server) may be encrypted via Secure Sockets Layer (SSL) and a server-side certificate, thus providing authentication, privacy, and message integrity. Using standard Java cryptography libraries, you can encrypt and decrypt files, create security keys, digitally sign a file, and verify a digital signature.

User name and password security is enforced whenever a client attempts to invoke an Agile Integration Service operation.

For more information about Java security and cryptography support, refer to the following Web page: http://docs.oracle.com/javase/1.5.0/docs/guide/security/index.html.

  Previous
Previous 		 Next
Next
  Go To Table Of Contents
Contents