Metasolv software

One of the most important tools provided by the APIs is the ability for your applications to integrate with the Work Management subsystem. This integration is provided by the exchange of events and signals between the APIs and your applications. An event is a significant occurrence within the workflow of either the Work Management subsystem or your application.

A signal is the logical artifact used to communicate information about an event between MetaSolv Solution and your application. Application events are pre-defined within MetaSolv Solution and occur at fixed points in the workflow. Application events are always sent by MetaSolv Solution to external applications via an outbound signal that carries MetaSolv Solution-defined data pertaining to the event.

The signal that represents an application event carries pre-defined data specific to that event. Gateway events provide a powerful mechanism for you to insert hooks into the Work Management subsystem. The signal that represents a gateway event can carry only generic data such as a document reference for a document in the MetaSolv Solution database. Except for the system-defined gateway events used by the PSR Ancillary API, all gateway events are defined by your application and set up in the MetaSolv Solution database using the user interface provided in the Work Management subsystem.

Unlike application events, which can only occur within MetaSolv Solution, gateway events can occur within either MetaSolv Solution or your application. Therefore, gateway events must be defined in the MetaSolv Solution database as either outbound or inbound events. Outbound gateway events occur within MetaSolv Solution and are communicated to your application via outbound signals.

Inbound gateway events occur in your application and are communicated to the MetaSolv Solution Application Server via inbound signals. Your application communicates the status of outbound gateway events to the MetaSolv Solution database through the APIs. These statuses indicate changes in the state of the event. The actual status values available for your use are defined in the event-signaling structure of the MetaSolv Solution IDL.

Gateway events must be tied to a task in a provisioning plan in the Work Management subsystem. When that provisioning plan is associated with a new order, the plan ensures that the Work Management subsystem sends or receives the gateway event at the point defined within the provisioning plan.

Table summarizes the differences between application events and gateway events. Defined by you or a third-party developer and added to the MetaSolv Solution database using the Work Management subsystem's user interface. For more information about Work Management integration, contact the Oracle representative at the implementation site. All external applications those developed by you or a third party that interact with the APIs are required to handle both invocation modes.

This means your application is required to return the results of the operation upon return of control. All operations your application invokes on an API server are synchronous, except for data import and export operations, which are asynchronous. In the scope of this documentation, asynchronous operations are those where control returns to the application immediately and the results if any are returned to the invoking application at a later time. The APIs use a callback mechanism to implement this paradigm.

The callback mechanism works as follows:. Your application creates a unique callback object, then passes that object to the appropriate API server along with the rest of the asynchronous operation's parameters. Your application then awaits return of control. The API server implements the operation and immediately returns the call.

Results of the operation are not returned at this time. Control returns to your application, which now begins to listen to the callback object while it waits on the results.

The asynchronous operation completes the requested task and returns the results to the API server. The API server invokes an operation on the callback object to return the results to your application. The general rule for asynchronous operations is that all operations involving movement of data to and from the MetaSolv Solution database, data import and export, are asynchronous. The APIs use a transaction model; however, the APIs do not provide built-in support for nested or linked transactions.

With two exceptions, the API servers provide an operation that external applications can invoke to generate a transaction object. These two servers provide all required transaction management functions internally. Operations that involve movement of data into or out of the MetaSolv Solution database require the external application to supply a transaction object.

The transaction object must support two operations:. A commit operation that unconditionally applies all database changes that were performed during that transaction. The responsibility of organizing and managing units of work using the commit and rollback operations rests solely with external applications that use the APIs. Each API server maintains an internal table of all the transaction objects it generates. The scope of a transaction object is ultimately limited to the lifetime of the API server process that created it and the lifetime of the MetaSolv Solution database instance.

Transaction objects are re-useable but not portable. This means that the same transaction object may be used multiple times while performing operations on the API server that generated it, subject to the transaction lifespan limitations described earlier in this paragraph. You can only use a transaction object on the API server from which it was generated.

When developing an application to run against any of the APIs, it is very important to understand the roles that application will be performing. Applications can be developed against the APIs to perform in one of the following roles:.

Because of the significant differences between developing for these roles, it is important that you understand the differences between the roles.

Before beginning development you should determine which role your application will perform in relation to the APIs. For synchronous transactions each application's role remains constant throughout the transaction and is either the client role or the server role.

See "Synchronous Operations" for more information. When your application invokes synchronous operations on the API servers to update the status of gateway events, your application is the client. In this case, your application requests the service and the API server supplies the service. When the Work Management subsystem sends an outbound gateway event to your application, your application is the server.

MetaSolv Solution requests the service in this case, WDISignal::eventOccurred and your application supplies the service; in this case, whatever the application does when it receives that particular gateway event. For asynchronous operations, the server role is also determined by which application requests the service, but the role each application plays can change, so role determination is not as simple as in synchronous operations.

Then, do a full installation of the Oracle WebLogic Server If you have MSS 6. When planning your upgrade to MetaSolv Solution 6. The 6. While these changes, features, and fixes are included in the 6. If you are currently on a release prior to 6. Refer to the appropriate sections of the following documents, depending on which release you are upgrading from:.

The following terms are used throughout this guide. They are basic terms necessary for the discussion of deploying an application intended for use over a network by many users. In a 3-tier client-server environment, the application server performs the business logic processing between the user's machine first tier and the database management system third tier. A simple example is shown in Figure The MetaSolv Solution business logic, designed to work with the WebLogic server software, is loaded on the same machine and connections are established between the two to allow the exchange of data.

Connections are also made between the application server software and the database. The following list shows the benefits of using an application server approach:. Processing tasks are moved from the client workstations to the application server machine, which saves resources.

More users can be supported, and you can set up your system so processing continues if a server fails. Delay between the application and the database server is minimized, increasing the efficiency for processing requests. A domain is a group of application servers managed as a single unit. The domain contains at least one instance of WebLogic Server. If multiple server instances exist in the domain, one instance is designated as the administrative server, and the rest become managed servers.

Managed servers are controlled from the administrative server console. The administrative server allows you to manage other servers in a domain. This server has a console that allows you to shut down and start up other servers, monitor the environment, and manage activities like security and transaction processing.

A cluster is part of a domain dedicated to some specific processing duty for example, MetaSolv Solution processing. A cluster is not the same as a domain but is a subset of a domain.

A cluster generally includes several server instances, and the servers work together as if they were one application. A single cluster or multiple clusters can exist in a domain, but you cannot spread a cluster across more than one domain. One advantage of clusters is their scalability; you can increase the number of servers in a cluster to handle increased processing needs.

Clusters also give you high availability, which means if one server fails, another replaces it without the loss of data. The client is the user workstation linked to MetaSolv Solution so that a user can interact with the system to carry out tasks.

Some application code is loaded to the client to allow the execution of some MetaSolv Solution graphical features and other processing tasks. JEE is a standard for developing Java applications for a thin-client, multitiered environment. The conventions found in JEE help ensure applications are developed in such a way that communications are simplified between Java applications.

MetaSolv Solution contains three discrete software installation processes: database, application server, and client. The installation is completed in the following order:. For MSS 6. Data Selection Tool How-to Guide. Provides an overview of the Data Selection Tool and includes procedures on how to use the tool to migrate the product catalog, equipment specifications, and provisioning plans. This guide is for individuals who are responsible for migrating data from one release of MetaSolv Solution to another.

Operational Reports. This guide is for individuals responsible for running reports to access critical information maintained within MetaSolv Solution. Describes new features, fixed issues, known problems, and deprecated or removed features in this release of MetaSolv Solution.

Licensing Information User Manual. Custom Extensions Developer's Reference. Describes how to extend the MetaSolv Solution business logic with custom business logic by using custom extensions. This guide is for developers responsible for integrating external applications with MetaSolv Solution. Flow-through Packages Guide.