App Server to Database Reconnection issues in 8.51

I ran into a problem a while ago which brought a more severe problem to my attention.  It appears in at least 8.51.02 (but probably back to 8.51.00) to 8.51.09 there are issues with application server processes properly recovering from a disconnection from the database.  I don’t have first hand experience with that problem, but there is some info on Oracle’s support site about it. If you are running in this PeopleTools range and experiencing odd crashes every once in a while this may be worth investigating.  Using Tracesql=31 will create ORA-3113/3114 errors in your logs.  In 8.51.08 a patch went in to fix it, but it broke something else, causing the problem I encountered.  Bug 11724645 has the details.

My particular problem was experienced on 8.51.09 and was limited to only the Integration Broker PUBSUB processes.  So apparently the PSAPPSRV code had been fixed by then as I never had a problem with those.   In this post I’ll discuss what I saw, some of the troubleshooting steps I used to isolate the problem, and some options I came up with to resolve it.

The Problem:

Integration Broker stops processing messages.   The processes don’t crash and look OK from a quick glance (psr and Process Explorer), but do nothing.  The environment was 8.51.09 all Windows 2008 on SQL Server.  The problem occurred everywhere, even in environments that restarted nightly.

Diagnosing the Problem:

I knew from day one something strange was occurring.  I had never needed to restart the PUBSUB processes this often ever before.  Almost daily some environment would need restarted, sometimes multiple environments, sometimes ones that had already been restarted.  Obviously it was off to the logs first.  There I found something interesting.  Here’s an example, the tables might be different depending on the processes (PSPUBDSP, PSSUBDSP AND PSBRKDSP), but the main message is always the same:  The SELECT permission was denied on the object

PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:25](3) File: E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cppSQL error. Stmt #: 67  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSAPMSGDSPSTAT’, database ‘HCMDEV’, schema ‘dbo’. (SQLSTATE 42000) 229
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:25](1) GenMessageBox(200, 0, M): E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cpp: A SQL error occurred. Please consult your system log for details.
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](3) File: E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cppSQL error. Stmt #: 663  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSAPMSGSUBCON’, database ‘HCMDEV’, schema ‘dbo’. (SQLSTATE 42000) 229
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](1) GenMessageBox(200, 0, M): E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cpp: A SQL error occurred. Please consult your system log for details.
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](3) File: E:\pt85109b-retail\peopletools\src\psmgr\mgrvers.cppSQL error. Stmt #: 881  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSVERSION’, database ‘HCMDEV’, schema ‘dbo’.
[Microsoft][SQL Server Native Client 10.0][SQL Server]The cursor was not declared. (SQLSTATE 37000) 16945
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](1) GenMessageBox(200, 0, M): E:\pt85109b-retail\peopletools\src\psmgr\mgrvers.cpp: A SQL error occurred. Please consult your system log for details.

My first reaction was to check the permissions for the ACCESSID user and of course, nothing was out of the ordinary there.  I searched Oracle support and found a case indicating that I needed to Synchronize the ACCESSID after a Tools upgrade to 8.50+ on SQL Server, but from what I could see the account was setup just fine.  That’s when I took a look at the database connections and saw something bizarre. There was a connection to the database as user people. I waited a minute and looked again, the same connection was still there as people.  Now that shouldn’t happen.  As you should know, the people user is very limited in what it can do.  It’s really only used to validate OPERID’s and retrieve the ACCESSID and password.  I queried sys.dm_exec_sessions, I wanted the host_process_id so I could see what process was connected as people for so long.

login_name session_id login_time              program_name host_process_id status
psaccess   77         2012-01-28 04:16:11.970 PeopleSoft   5624            sleeping
people     81         2012-01-28 04:16:12.030 PeopleSoft   6076            sleeping
psaccess   82         2012-01-28 04:16:12.030 PeopleSoft   5612            sleeping

Once I got the host_process_id, I went back to the app server and confirmed what the log was already telling me.  PID 6076 on the app server was the PSSUBDSP process.  The same one that didn’t have select permission anymore and of course it couldn’t select, it was connected as people.  I also noticed the login_time of the processes seemed odd.  I didn’t restart that system at 04:16 and in fact looking at the processes in Process Explorer indicated the processes had been running quite a while longer.  Now the processes will restart after a certain amount of work load, but that should rarely have them all reconnecting to the database at the same time.  In the logs I didn’t see anything around that time, in fact, the errors didn’t show up until several hours after the login_time.

I restarted the PUBSUB processes and saw that after restarting all processes were once again connected as the ACCESSID.  I decided to see what happened if I killed the connection for the process from the database.  I killed a newly connected PSSUBDSP process by matching the session_id from sys.dm_exec_sessions with the host_process_id again.  The process reconnected as people and never made the switch to the ACCESSID again.

The Test Plan:

I decided to dig in a little deeper.   I was going to file a case with Oracle since I had not found anything on their support site that seemed to address this at all.  I also wanted to have someone else try to replicate it on a different version of PeopleTools.  Plus I didn’t know why the error didn’t really show up until some time later.  To make this section shorter, I did several things to validate my theory (after network/database disconnection the reconnect process was broke) and ensure I had the detail needed for the support case.  I validated outbound port numbers changed with netstat, turned up tracing a bit, and forced messages through.  Something I found during this was that the error would not start showing in the app server logs until a message had tried to be processed.  I ended up coming up with the following test plan to provide to Oracle and others to use:

  1. Set TraceSql=7 in psappsrv.cfg
  2. Review newly created <USER>_PSSUBDSP_dflt.tracesql log to determine pid for PSSUBDSP process
  3. While reviewing the log, verify that after every SQL statement is run transactions are “commited”;  look for a line like:
    PSSUBDSP_dflt.17196 (4)      1-3      16.25.27    0.005000 Cur#20.17196.FINDEV RC=0 Dur=0.003000 Commit
  4. Run netstat -a -o |find “<pid>”  : noting outbound TCP port
  5. Determine SID to kill and the user it’s logged in as
    select session_id, login_name from sys.dm_exec_sessions where host_name=”<App Server HOSTNAME>” and host_process_id=<pid>
  6. kill <sid> :  to kill connection
  7. Wait 15 – 30 seconds
  8. Rerun netstat -a -o |find “<pid>”  : noting outbound TCP port, did it change?  it should have.
  9. Review <USER>_PSSUBDSP_dflt.tracesql log to determine if transactions are now failing; look for a line like
    PSSUBDSP_dflt.17196 (62)      1-3      17.00.24    0.002000 Cur#1.5844.FINDEV RC=0 Dur=0.001000 Rollback
  10. Rerun the SQL above to determine if the login_name has changed
    select session_id, login_name from sys.dm_exec_sessions where host_name=”<App Server HOSTNAME>” and host_process_id=<pid>
  11. If login_name = people or transactions are saying Rollback in the log, you have a problem, review APPSRV log to check for the following errors. None should exist until the next message is processed. PSSUBDSP_dflt.5844 (63) [11/12/12 15:14:56 Dispatch](3) File: E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cppSQL error. Stmt #: 67  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSAPMSGDSPSTAT’, database ‘FINDEV’, schema ‘dbo’. (SQLSTATE 42000) 229
    PSSUBDSP_dflt.5844 (63) [11/12/12 15:14:56 Dispatch](1) GenMessageBox(200, 0, M): E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cpp: A SQL error occurred. Please consult your system log for details.
  12. Force a message through the system. I was just locking and unlocking my account on the HR side to force the message over to another application.
  13. Check to see if the message was processed and review APPSRV log for error.
  14. Test either Passed: Message proccessed ok, or Failed: Message stuck in New status on subscription side and error in the APPSRV log.
  15. Set TraceSql=0 in psappsrv.cfg
  16. Restart PUBSUB processes to correct any connection problem.

The Fix:

In a test environment I validated that the PUBSUB processes were fixed in 8.51.10, unfortunately, a minor PeopleTools patch was not an option at the time for production, so a work around was in order.  What would be the best way to identify this problem and take corrective action?  If you’ve read some of my other posts you might know blindly restarting every night isn’t my style, and as I saw didn’t guarantee anything.  What ever was causing the disconnect could happen any time, you might need to restart every 30 minutes to ensure a decent availability for integration.  I needed to detect the problem, identify which database on the SQL Server was impacted, and restart only what was impacted.  Time to break out my scripting fingers.  I came up with two scripted solutions.  The first solution I wrote was a SQL script that could be scheduled which would:

  1. Identify connections to the database as people that were older than X minutes
  2. Execute a power shell script on the database server providing  the server name, database, and host PID of the offending process
  3. That database server side PowerShell script would then remotely execute PowerShell commands on the correct app server which
  4. Ensured the host PID provided was for a PUBSUB process and
  5. Executed my normal PUBSUB restart script for the domain

This method had several challenges that I did not try to overcome really.

  1. The database user running the SQL script needs xp_cmdshell.  This is a big security concern in many shops and in general something that should probably be frowned upon.  It would probably be easy enough to have the PowerShell script run the SQL and collect the data as well.  But I didn’t look into it.
  2. My SQL script assumed the app server domain running PUBSUB was the same as the database name.  If you ran multiple or different named domains it would need to be tweaked to take those into account.
  3. Remote PowerShell capabilities had to be turned on, another possible security concern.

I also wrote another Powershell script that was application server side based.  I have a large script infrastructure that is already deployed to any windows app servers that some what mimics on the nix servers.  This script leverages that infrastructure, and with one additional script, I can monitor all domain APPSRV logs on a server for the error.  This script does the following:

  1. Reads a central file that includes all application domains on the server
  2. Uses pattern matching to find a domain with “select permission was denied” in the log file
  3. If an error is found, the script waits for 20 seconds and rechecks the log file
  4. It compares the number of error lines before and after the 20 seconds (default polling interval is 15 seconds)
  5. If the count increases, it restarts PUBSUB and emails me notification of the restart
  6. If the count is the same, we must have restarted previously, so we do nothing

This method also has some disadvantages, but is the route I chose

  1. It won’t detect the problem until the error is in the log, which could be hours later.  However, there is no user/functional impact until the error arrives as that is the first time a message is actually processed.
  2. I’m not doing anything fancy to track file offsets and start reading where I left off, therefore, the larger the file the longer the script will take to run.  I would not recommend running this against log files that are growing really large or have tracing on.
  3. This script needs to be scheduled on each physical application server instead of a smaller number of database servers.

I never did identify the real culprit of why the processes are being disconnected from the database, it seems to be pretty hit and miss.  I had some ideas, but once I got the automatic restarts scheduled everyone’s interest in the problem died down significantly.

Determining psjoa.jar Version

I recently answered a question on the OTN forums that I thought was interesting and figured I’d detail it a little further here.  Someone was using psjoa.jar to interface with a remote PeopleSoft system and wanted to verify what PeopleTools version a specific psjoa.jar file was from.  First a little background on psjoa.jar.  This file is a package of java classes that can be used to interface with PeopleSoft.  It’s required by a multitude of 3rd party applications and adapters which wish to interface with PeopleSoft.  It can also be used to expose Component Interfaces to your own Java applications, which I may detail in a future post shortly.

Here’s how I found the version and created the solution:

First it helps to know that psjoa.jar can be found in $PS_HOME/appserv/classes.  So I ran unzip -c psjoa.jar | strings |grep 8.52.  8.52 being my current major tools release version for this file.  unzip -c extracts to stdout and then I piped that to strings and from there to grep.  If your wondering why I ran unzip it’s because the jar contents are compressed which garbles everything useful that strings might give me from each individual file in the jar.

$ unzip -c psjoa.jar | strings | grep 8.52

Okay, so I knew the version was in there a few times and since strings was able to see it, it’s in a readable format.  Now lets find out where exactly, so I unzipped psjoa.jar to a temp directory and I ran find on the directory using the -exec option to run grep -l on every file so I would just get the file name of every file that matches.

$ mkdir /tmp/psjoa
$ unzip psjoa.jar -d /tmp/psjoa/
$ find /tmp/psjoa -exec grep -l 8.52 {} \;

Okay, so I got a few options and these sound promising… promising in that they hopefully won’t disappear in the next version.  So I had half a solution, by grepping for a regex pattern that matches a tools release. So something like

unzip -c psjoa.jar |strings |grep 8″\.”[4-5]

would work, but I was looking for something more (as was the poster since they were on Windows and was trying to build this into something web based on their end I think).  So I imported psjoa.jar into a project in Netbeans to take a look.  After looking at the above classes in Netbeans I found ND would be the best class.  ND is an interface that contained public static final variables only, that’s perfect.  I showed the OP he could just import and then print out the variable TOOLS_REL and build that into a jsp page or however he would like to deploy it.  One thing to remember about this is that final static primitive or String constants will be replaced to their value at compile time, the bytecode will not contain a variable anymore but the value directly.  So just compiling the program with ND implemented will cause every version we check to always be that of the file used to compile and that won’t do us any good.

same version

Notice in the above screenshot both psjoa.jar and psjoa2.jar indicate the same PeopleTools release.  But psjoa.jar is from 8.51 and psjoa2.jar is from 8.52.  So since this a really simple single purpose utility with only one line I created a new ND.class to use at compile time that forced the variable to no longer be constant.  The cloned ND.class is only for compile time, during runtime we find the real file and the compiled code  needs to look up the value from the file every time.  Exactly what I wanted.  Now I have a simple cross platform utility to check the version.

different version

I’ve posted this program in my new Downloads section.  Because PeopleTools 8.53 is now built using Java 7, this utility is best run with the Java 7 JRE.  I compiled it with support back to Java 5, however if your using Java 6 to look at a psjoa.jar file from 8.53 which was built with Java 7 then you’ll get the error “Unsupported major.minor version 51.0” because psjoa.jar itself is not compiled with the backwards compatibility.  51 in the error indicates the ND.class being imported requires Java 7.  PeopleTools 8.49 was the first version to use Java 5, so this version of the utility will be limited to testing 8.49+ psjoa.jar files.  I’ve run it on 8.49, 8.51, 8.52, and 8.53 and it worked on all 4 of those.

PeopleSoft Unified Navigation with PeopleSoft Applicatations Portal / Interaction Hub

With Portal 9.1 Feature Pack 1, which was released just over a year ago, came a new feature I finally got the chance to use. Unified Navigation. In this post I’ll walk through setting this up in one of my demo environments.

Using the Unified Navigation WorkCenter makes configuring this feature pretty easy to set up.  And it certainly does seem to take care of the mess of managing security and content references between all your systems.  Oracle has put quite a bit of effort into making the configuration of Integration easier.  With the introduction of the IB Network WorkCenter, configuration of IB has been simplified.  Setting up Unified Navigation leverages the IB Network WorkCenter and the new Unified Navigation WorkCenter.

Before getting started, lets go over a few details.  Keep in mind I am not an Oracle representative and the information I’m providing  in these next bullets is only rehashing item’s I’ve seen in information published by Oracle.

1.  Unified Navagation requires a full fledged license of PeopleSoft Applications Portal if your running PeopleTools 8.52.

2.  PeopleTools 8.53 modified the limited use license for PeopleSoft Applications Portal so starting with 8.53 you can now use Unified Navigation for free if you own PeopleTools 8.53, I don’t know if this is retroactive back to 8.52 or not, talk to your Oracle rep. or just upgrade 🙂

3. There are several limitations in 8.52, I’ve not found documentation indicating that there was any change to these limitations in 8.53 yet.  These are described in more detail in the PeopleSoft Applications Portal 9.1 PeopleBook: Portal and Site Administration

  • The full license was originally needed and may still be required.
  • Unified Navigation is not supported as a pagelet, although a pagelet does show as available, documentation indicates it is for use in the WorkCenter only.
  • Navigation to the content providers is supported through the drop-down menu only.  I’ve worked several places where clients have disabled the drop-down menu for their own reasons.  A lot of the time this is because they still have pre 8.50 releases and want to keep a more uniform appearance.
  • Some files may need to be copied to the portal system: Any remote pagelet icons needed and CSS files (only if the portal and contenent provider don’t use the same style)
  • Unified Navigation is only supported for like portal types (EMPLOYEE to EMPLOYEE, CUSTOMER to CUSTOMER, etc.  not EMPLOYEE to CUSTOMER)
  • Character limitations on remote folder names are: { } #
  • Can not add subfolders to a unified navigation remote folder (it looks like you could do that, but it’s not supported).
  • Templates for remote CREFs and remote Dashboards need to conform to standards that are outlined in the Applications Portal 9.1 PeopleBook: Portal and Site Administration

4. Documention indicated that this function could work with Content Provider systems at 8.50+ however other information points to all systems needing to be at least 8.52.02 or later.

Okay, on to the real work.

I will be assuming that your environment is already functioning in a pre 8.52 state.  That is, that IB is setup properly to do the following:

  • Gateway(s) are setup properly
  • Nodes are configured and authentication type is set
  • Single Signon is already configured and working
  • Old methods of Portal Navigation already work

Before I started I did some sanity checks on my environment.  Could I ping all nodes and did the original method of Single Signon work?  I used the PeopleSoft > Financials Supply Chain PT8.4x link to test and it popped me right in to Finance just like I would expect.  Also I tested the Portal Administration > Test > Single Sign On > User Profiles link for my content database. Another success, with that we should be good to start.

Some additional configuration steps are required before we move forward.

  1. Ensure the authentication domain matches for all systems involved
  2. Unified Navigation requires the “generate relative URLs” option be turned off on the Virtual Addressing page of the web profile in use.  This is on by default in all the delivered web profiles as far as I know.  Disable it on all systems involved and restart the web server or use the reloadconfig  command if you have that set up.
  3. All systems require the drop-down menu to be enabled, as previously stated it only works with the drop-down menu, not the pagelet menu on the left hand side.  Enable it if you have disabled it.
  4. On the content provider side a default user id must be set on the ANONYMOUS node, the user should be in both the content and portal system.  Oracle recommends that it be a very low priveleged user.  This also could impact pre-existing configuration required for integration. If your not already using the ANONYMOUS node, I recommend creating a new user for this purpose.  Give this user id access to run the PTUN_SSOTESTER service operation.
  5. On the portal side, create a new node for the PTUN_SSOTESTER sevice operation, copy an internal node to fulfill this. The settings should be confirmed: active = yes, segment aware = yes, authentication option = none, WS Security authentication token type = none, routings = none.  Once the node is created, create an outbound routing for the PTUN_SSOTESTER service operation to your new node.  Deactivate the routing to the WSDL_NODE if it is activated.

1, 2, 3, I took care of easily enough. For 4, I created a new permission list, role, and user specifically for this purpose and assigned that user to the ANONYMOUS node, changing it from the PSADMIN user which is delivered.  I added the user without any role and permissions to the portal system.

UNINAV permlist

Create a Permission List

UNINAV permlist 2


UNINAV permlist 3

Edit the Permissions and set PTUN_SSOTESTER to Full Access


Add the new Permission List to the Role


Add the new User


Add the Role to the User

For number 5, I copied the ANONYMOUS node to RP_UNINAV.  By default, the node was active, segment aware, and had an authentication option of none.  The WS Security authentication token type was also none.  If for some reason you’ve changed these on the node you copy from you’ll need to update them.  I verified no routings existed on the node and proceeded to edit the PTUN_SSOTEST service operation.  I inactivated the existing active routing on the WSDL_NODE and added a routing for my new node.

UNINAV node in portal

Create a new node in Portal

UNINAV routing

Pull up the PTUN_SSOTESTER routings

UNINAV routing 2

Deactivate the WSDL_NODE routing and add a new one for your new Node

In order to proceed further, we need to start making configuration changes that, at the moment, I’m not that found of, mainly because it appears we need to use the new IB Network.  I may add reference to why I’m not thrilled with this later.

In both Portal and your Content systems navigate to PeopleTools > Integration Broker > Integration Network.  If your like me and this is your first time here, even though things are running fine, you’ll most likely find that it says the Node Network is Not Configured.

IB Network Config Status 1

Click the link, click save on the following screen, return to the configuration status and things should be good to go.  Saving at that screen officially updates the IB_NETWORK status for the default local node for the first time if it hasn’t been updated by something else already.

IB Network Config Status 2

If after returning the status is still not configured, go back and make sure read the notes at the bottom, at a minimum you must have the default local node configured and part of the network, the integration gateway secure keystore must be set, and any nodes configured but not in the local gateway must have a remote gateway configured.  Look to make sure it’s detecting that your secure keystore is setup properly, there will be a checkmark in the Secure Keystore Value Defined in the top left of the page.  Last I knew Oracle was still delivering the keystore password unencrypted and you had to change that to fix it.  Going forward with PeopleTools 8.53 I believe they are prompting you during install for these passwords.

I’m setting this up in Portal and Finance, therefore, in Portal I should have PSFT_EP setup as a remote messaging node and ERP setup as a portal node pointing to Finance.

portal node config

Conversly in Finance, I would setup PSFT_PA as a messaging node and EMPL as a portal node pointing back to Portal.  I already had this done, as I said this was an already working environment, so nothing for me to change here.

Tthe documentation indicates that these Portal nodes must be added to the new Integration Network facility in order to complete the configuration.  The only way to add them though is to add them to a Gateway (either local or remote).

Unified Navigation WC 1

This appears to only be required on the Portal side.  I added ERP to the gateway that Portal was using, and then was able to add it to the IB Network.  After I added it to the network it was available to choose for the Drop Down Menu configuration and SSO test.  I did not add EMPL to a gateway or IB Network on the Finance side and things worked just fine.

SSO test ERP

After adding the corresponding portal node(s) to your gateway(s), add them to the Integration Network.  Once that is complete, go to Portal Administration > Unified Navigation WorkCenter, expand the Unified Navigation Setup section and test the single sign-on to the Portal node (ERP in my case).  After the test completes successfully, move on to Configure Drop Down Menu.  Select the portal node reference, you’ll notice, only nodes in the Integration Network are available for this selection, thus driving the need to actually add these portal purposed nodes to the gateway as I mentioned previously.  For Folder Label, specify a name you like, such as, Finance Menu or PeopleSoft Finance 9.1.  Folder Name is the content provider menu navigation to share, use the lookup button and the returned tree to select what to bring over.  This allows you to do partial or full menu, for instance, my example does the full tree, but you could choose to do three individual subfolders, and set them up independently.  Local Parent Folder Name is the same as Folder Name but it’s the corresponding location to place the menu on the Portal side.  They are pretty self explanatory.

Drop Down Menu Config

And here is the final product, note the Fianance Navigation at the top of the drop down menu expanding all options since I’m logged in as an admin.

FIN Nav menu

This is a pretty nice update in my opinion.  Doesn’t take long to setup, especially if you already had things working, and is much cleaner than moving CREF’s and security around to provide navigation.  [Edit] Screenshots added


As reference, here’s the link to the PeopleBook for 8.52

Cannot establish HTTP connection

Recently I had a problem with a WebEx PeopleSoft setup.  Users testing in a development environment were reporting they got the following error “Cannot establish HTTP connection (158,2842)”.  I tried pinging one of the external nodes used for WebEx.  I also received “Cannot establish HTTP connection”.  The URL defined on the node looked OK, and I could hit it from the server.  It was an HTTPS URL and the browser validated the certificate, so I decided to look at the SSL Keystore configuration in the file.  There I found the answer.

In the file there are two values for the keystore. secureFileKeystorePath, which is the full path to the pskey keystore file and secureFileKeystorePasswd, which is the password to the pskey keystore file

By default the password in this file is delivered unencrypted.  However starting with PeopleTools 8.50 (I think it was) it’s now mandatory to encrypt the password. In this case, for whatever reason, we still had the unencrypted default password.

You can use or PSCipher.bat on the command line to get the encrypted string or you can make the change online in the Gateway Setup Properties using the Advanced Properties Page.  The password encryption tool is built into the bottom of the page.

FILEOUTPUT target connector

Someone called the other day. They were trying to use the FILEOUTPUT connector. They were getting the following errors
Integration Gateway: Password is either missing or invalid. (158,10633) when pinging the node and
PublicationContractManager::ProcessError/RetryResponse(): 'Integration Gateway: Password is either missing or invalid. (158,10633)'. in the publication contracts error log.
By default in the files we have the following:
#File connector password.
# Use the supplied encryption utility to provide an encrypted password for the entry below

If your not specifying a password property on your target connector then you should comment the ig.fileconnector.password line out. Better yet though, I would create an encrypted password and use it on the connector and update the corresponding line in the config file.

Once the password mismatch is resolved things should start working.