Current version 6 of prosight upgraded to version 7.5. We are having our external webservice consumes Prosight webservice which defaulted installed under ProsightWS virtual directory. After up gradation we are running into issue in external application ,application unable to communicate to Prosight new version webservices. Fails in the time of calling in Login method itself in the psPortfoliossecturiy service.
Exception as follows:
“System.Web.Services.Protocols.SoapException: Could not create Security Token for specified User and Password at ProSight.Portfolios.WebServices.WS.psPortfoliosSecuritySOAP.Login(String sUser, String sPassword, Int32 lTimeOut) “
Our web application uses a dedicated user account to interact with Prosight webservice and it runs under windows authentication. Application build on ASP.NET 2.0 and later.
The sad part here is , our web application running perfectly with Prosight v6. :( I would appreciate if anyone could help us to resolve this issue. This is blocking our up gradation from 6 to higher version of prosight.
the APIs and Web Services are always critical; the problem arises also between P6 7.0 and ProSigth 7.5 SP1, which are not compatible. So in this moment companies who rely on P6 Bridge cannot upgrade to P6 7.0 until the new version of Prosight (or at least of the bridge) will be released.
I am the Prosight Administrator for the US Department of Health and Human Services. I am in the process of upgrading from Prosight 6.0 to Prosight 7.5. We are upgrading hardware, DB, and the application. Environments detailed below:
Our current environment is single server Production (Prosight 6.0, Oracle 9i, O/S Server 2K3 SP1 – 32bit) and single server Development (Prosight 6.0, Oracle 9i, O/S Server 2K3 SP1).
The new environment for Production is dual servers (DB and App); App Server (Prosight 7.5 SP2-32bit Frontend, Oracle 10g-32bit, O/S Server 2K3 SP2-32bit), DB Server (Prosight 7.5 SP2-64bit Backend, Oracle 10g-64bit, O/S Server 2K3 SP2-64bit). The new Development environment is a single server (DB and App) running Prosight 7.5 SP2-32bit Frontend & Backend, Oracle 10g-32bit, O/S Server 2K3 SP2-32bit.
Installation complete, system testing under way on the new Production environment. Attempting to establish the GUI (App server) to communicate with the DB server; I have been able to SQL Plus communicate (pull data/rows), but still working the GUI communication issue.
The new Development environment is setup and functioning, however nightly the Oracle 10g comes down and brings down Prosight. We currently have a “de-tuned” RAM 3GB switch to run the Oracle 10g in a the 32-bit O/S environment. I have a fourth server that I plan to convert this environment to a dual server with the same O/S, DB, and Application versions as our Production environment.
I have 3 custom tool Add-ons in my current Prosight 6.0 environment. Prosight has informed me that the Prosight 7.5 64-bit does not support Add-ons, fortunately I have installed Prosight 7.5 32-bit on my App server (supposedly 7.5 32bit does support Add-ons). I plan on starting the process of installing the Add-ons in the next few weeks. The Add-ons consist of a System Generation utility (glorified Excel Spreadsheet) to establish a Portfolio, Export specific Portfolio items, Import specific Portfolio items)
Do you know of any issues I may run into?
I have a xml import process I run a few times a quarter, using the Prosight APIs/SOAP process. I will begin testing this process in the coming weeks also. Any known issues/changes with APIs in 7.5?
Here is the offical documentation from version 8.0 on the backward-compatability of the APIs. This document comes the version 8 installer. Not sure this helps you with the 7.5 issues, but hoping it will help:
Considerations for applications using the PPM Open API via COM
Applications which use the Primavera Portfolio Management (PPM) Open API via any interface (COM, SOAP/RCP or Document/Literal) and were developed and used with previous versions of PPM will continue to operate without the need for recompilation, as Primavera Portfolio Management 8.0 provides full binary backwards compatibility for all of the Open API interfaces. New functionality is available only to applications that are written to take advantage of such functionality.
Note however that any process can only load and use one version of the Microsoft .NET Framework. Therefore, applications developed with the .NET Framework 1.1 cannot use APIs to communicate with software developed using the .NET Framework 2.0 if this would cause the same process to need to load both versions of the .NET Framework.
This means that if any part of an application that uses the Open API which was developed using .NET Framework 1.1 communicates directly with PPM using the COM API (which is in-process), that part of the application would need to be recompiled to target the .NET Framework 2.0. If on the other hand, the application developed using .NET Framework 1.1, only communicates with PPM using SOAP RPC or Web Services (which are out-of-process) then there is no issue.
Instead of recompiling, it is usually sufficient to ”force” the existing executables to actually use the .NET Framework 2.0 instead of the native version of the .NET Framework for which they were compiled (1.1). This can be achieved by using an application config file with the following content:
<?xml version ="1.0"?>
<supportedRuntime version="v2.0.50727" />
The application config file can easily be created using Notepad or something similar. It does not need to be compiled in any way. It should be named with the exact same name as the executable file plus the suffix “.config”. For example: if the application executable file is called “Tester1.exe” then the config file must be named “Tester1.exe.config”. It must be placed in the same directory as the executable file.
The config file “forces” the application to use the .NET Framework 2.0, which would mean that even when using COM (in-process) Open API calls to PPM, there would still be only one version of the .NET Framework involved in the process (.NET 2.0).
I was a fan of Oracle database for Primavera products, but sometimes it can be useful to look for the story behind products.
Also if Primavera (now Oracle Primavera) was largely oriented to Oracle for no standalone setup, the Primavera PPM (now 8.0) , formerly known as ProSight (up to 7.5) was acquired together with the company ProSight Inc. that developed the software.
As a result the two products have not the same historical background. ProSight is an IIS + .NET Framework application, i.e. a Microsoft oriented software, while P6 followed a more balance approach in used technologies.
As a result if P6 is about platform independent (for AS as well as for database) the PPM, originating in ProSight is actually a fully Microsoft oriented application.
I made some tests and found that the a fully Microsoft Oriented setup is the best solution for PPM (ProSight).
The setup I suggest is:
Windows 2003 x64
SQL 2008 x64
The x64 relates to the IIS process going often over the 2 GB limit for 32 bit (the problem of large transactions occurs also with any workaround as the /3GB boot option)
The SQL 2008 , better than Oracle, relates to
- the tight integration which governs far better process dependencies (never seen issues at startup) also when DB and AS were on the same server
- No need to setup Oracle MTS to integrate transactions management initiated in the application (Microsoft DTS)