Propagation O8 - O10g

Hi All!
Scenario:
O 8.1.7.4 propagation to 10g.
Error from prop. schedule:
ORA-02068: following severe error from DBL_BM
ORA-03114: not connected to ORACLE
ORA-02068: following severe error from DBL_BM
ORA-03113: end-of-file on communication channel
The dblink 'dbl_bm' works from SQLPLUS.
Appreciate for any idea,
Laszlo

I had a similar problem a couple of weeks ago, and found the underlying problem was NLS_CHARACTERSET differences. I could propagate a message from a queue in 08.1.7.4 to 9.2.0.4, but not to 10.1.0.3. See Metalink articles 234381.1, 237593.1, and 212043.1. However, I did NOT get the same error message numbers ... but atleast take a look.
I had to move my "receiving" queue to a 9.2 database to solve the problem.

Similar Messages

Error propagation

Hi,
I'm having a bit of an odd problem in Forms10g with the propagation of an error. I'll describe what happens:
I rightclick on an item, and select an action from a menu-item. In the code there is a call to a database package function where it is possible an application_error is raised (multiple values are possible, i'll use -20061 as example).
The menu-item code has an 'exception when others' clause, which obviously traps this error.
However...
(note: We have forms6 versions of our forms, who then are converted to a 10g version. The problem does not come from this conversion, i only mention this because the problem occurs differently for both)
In *6i*, the error is shown, though not correctly. The title of the alert would show the ora-number, but the message was also an ora-number, and not the expected message as was defined in the application_error. We then worked around this by trapping the code and message in a variable, using dbms_error_code and dbms_error_text, and showed these in an alert, faking the default behaviour.
In *10g* however, no dice. dbms_error_code is 0, and error_text is empty, resulting in a neat empty alert. Without faking the behaviour, it seems as there occured no problems to a user (no alert).
- i propagate errors trapped in 'when others' with RAISE
- Removing the 'when others' clause results in normal behaviour, in both 6i and 10g, showing the correct oracode and message.
- There was 1 more begin-exception when others-end block inside the main begin-end, i tried trapping the code/message there: no luck. Commenting out the 'when others': no luck.
- I then put a begin-exception when others-end around the call to the DB-function. In the 'when other' i trapped the code and message: correct values! When doing this, the values are propagated further and the main exception when others then shows my own alert with the correct values (dbms_error_text and code then suddenly can trap the values...). Only by trapping the values into a dummy var (or outputting them) maintains their value it seems.
I'm a bit bewildered:
- Do i really need to go ahead and put a begin-end around each of my calls to this db-function, and trap the error_text once, to correctly propagate the error thrown there? I'd just like to shed some light on this.
- How come a 'when others' blocks the correct working of the default alert?
Thanks.

Maybe can you tell me some usefull patterns?There's not much of a pattern here except for your (correct) MVC pattern.
Imagine this: something in the Model goes wrong. You don't want this
to pass by unnoticed. Your Model has no other way then throw an Exception.
Your GUI is way too stupid to handle business logic (as it should be).
So your Controller (the 'Logic') must handle the Exception, make the GUI
display a nice retry/cancel dialog (that's what it's good at) and make the
Controller try to solve the problem.
kind regards,
Jos

Updateable Snapshot changes not getting propagated

Hi,
I am using Oracle 8.1.7 with Updateable snapshot replication. When I do a dbms_snapshot.refresh as the repadmin user from the snapshot site, the changes I made to the table I am refreshing are not pushed to the master site. Also, the update is actually overwritten by the value that exists on the master site.
Here is the actual refresh call sql:
EXECUTE dbms_snapshot.refresh('scpa.dag', 'F', NULL, TRUE, TRUE, 1, 0, 0, TRUE);
What table can I look in to see whether or not my update on the snapshot site is queued.
I get no errors when I do the refresh.
Thanks,
Chris

Try check deferror view on master site. When you call refresh procedure you set parameter refresh_after_errors to True, so there can be same unresolved replication conflict. In DBA studio it is tab Errors for node
DB->Replication->Administration
If there are no record in deferror on master site, check if you snapshot is a member of snapshot group. If not changes is not propagated.

Message filtering in propagation process (stream replication environment)

Hi!
We have fine configured stream replication in star topology:
ORCL2 <=> ORCL1 <=> ORCL3
Where the ORCL1 is "headquarters" and there is no message flow between ORCL2 and ORCL3.
For some reason we want to filter messages in propagation processes, e.g. DML captured on ORCL1 should be replicated only to ORCL2 or only to ORCL3. There is one propagation process for each "satellite" database.
To solve this problem I have written function:
FUNCTION Replicate_Lcr (
p_lcr IN SYS.lcr$_row_record)
RETURN VARCHAR2 IS
which will be making a decision whether to pass the message (return 'Y') or not (return 'N').
But there is problem: rule is evaluated and function is executed (there is insert into 'stream_log_lcr' table) but value of the expression seems to be 'FALSE' and message (LCR) is not beeing sent to ORCL2 (or to ORCL3).
When I remove function 'Replicate_Lcr' from propagation rule condition then every message captured by capture process on ORCL1 reaches destination database (ORCL2 or ORCL3).
The second observation is that, if I run the same code on ORCL2 or ORCL3 then everything seems to be OK: there is insert into 'stream_log_lcr' table and DML captured on ORCL2 (or ORCL3) appears in ORCL1 ("headquarters").
I suppose that this could be problem with other version of database on "headquarters" (ORCL1) or configuration issues.
I will appreciate every suggestion.
Databases:
ORCL1: 64-bit Windows, ver. 10.2.0.4.0, Windows 2008 server
ORCL2: 32-bit Windows, ver. 10.2.0.1.0, Windows XP
ORCL3: 32-bit Windows, ver. 10.2.0.1.0, Windows XP
SQL code run on ORCL1:
CREATE TABLE stream_log_lcr (
data DATE NOT NULL,
msg SYS.lcr$_row_record NOT NULL
-- simplified, always return 'Y'
CREATE OR REPLACE FUNCTION Replicate_Lcr (
p_lcr IN SYS.lcr$_row_record)
RETURN VARCHAR2 IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
IF p_lcr IS NOT NULL
THEN
INSERT INTO stream_log_lcr
VALUES (SYSDATE,
p_lcr);
COMMIT;
END IF;
RETURN 'Y';
END;
-- create propagation process with above function in rule condition
BEGIN
DBMS_STREAMS_ADM.add_schema_propagation_rules
(schema_name => 'data_schema',
streams_name => 'primary_to_secondary2',
source_queue_name => 'strmadmin.capture_primary',
destination_queue_name => 'strmadmin.from_primary@ORCL2',
include_dml => TRUE,
include_ddl => TRUE,
source_database => 'ORCL1',
and_condition => ' strmadmin.Replicate_Lcr(:dml) = ''Y'' ',
inclusion_rule => TRUE,
queue_to_queue => TRUE);
END;
-- check if function 'Replicate_Lcr' was evoked:
SELECT * FROM stream_log_lcr ORDER BY data;

hi porzer,
In Propagation process ( source) also 0 errors. But in apply ( dest ) under statistics under server status is displaying as IDLE. And Coordinator status is APPLYING. In Capture (source) no error. In Applying ( dest ) no error. what else i can do please?
up to now what i did i am telling:
I had 2 databases had one table same table. one database i changed the mode to ARCHIVELOG mode. Another database is in NOARCHIVELOG mode only. In first database setup streams i run. And i run manually 2 .sql files and one .dat file like this :
SQL>@e:\oracle\product\10.2.0\client_2\sysman\report\OTEST_ADMIN_NON_OMS_SETUP.sql
SQL>host e:\oracle\product\10.2.0\client_2\sysman\report\OTEST_ADMIN_NON_OMS_exportimport.bat
SQL>@e:\oracle\product\10.2.0\client_2\sysman\report\OTEST_ADMIN_NON_OMS_startup.sql
Any thing else i can do? i didn't have metalink registration.i hope i am not boring you.
Thanks in advance.

Issue in propagating the fault in BPEL

Hi,
I have an issue in propagating the fault in BPEL.
This is the scenario,
a) I have a BPEL process which inserts data to a table, where a column is a primary key.
b) I invoke this BPEL as a partner link in another BPEL process.
c) I have provided catch for primary key violation in the invoking BPEL process.
Here, it throws below remote fault:
When invoking locally the endpoint 'http://localhost:7777/orabpel/default/InsertExceptionGen/1.0', ; nested exception is:
com.oracle.bpel.client.delivery.ReceiveTimeOutException: Waiting for response has timed out. The conversation id is bpel://localhost/default/HandlingESBFaultInsert1~1.0/20502-BpInv0-BpSeq1.6-2. Please check the process instance for detail.
But In the case of ESB, I could able to handle the primary key violation fault.
ie)
a) An esb process inserts data into a table, where a column is a primary key.
b) A BPEL process invoke this esb as a partner link.
c) In the invoking BPEL process, provided catch for primary key violation.
Pls. someone throw some light on this.
Thanks
Jude.

BPEL process should get a bindingFault for any application related errors.
since it received remote fault, may be some problem with connectivity.check the timeout values in the bpel configuration.

Limitation on principal name length due to propagation?

Is there a limitation on the java.security.Principal name length due to the underlying
implementation of the security context propagation, even though it is a java.lang.String?
Thanks,
Guillaume Bedard

Is there a limitation on the java.security.Principal name length due to the underlying
implementation of the security context propagation, even though it is a java.lang.String?
Thanks,
Guillaume Bedard

SSO and Principal Propagation in SUP

Hi all,
I am wondering how SSO and Principal Propagation work in SUP.
Ideally, users should be able to logon on their device application and the same user/pwd should be used to perform backend SAP invocations.
I have seen that personalization keys exists which can store users/passwords to use later in backend invocations.
However:
how can I perform login if my device is offline?
is the password used for login from device the same as the SAP system's?
do SUP and SAP have to share the same user engine (i.e. LDAP)?
Any help or pointers to best practices/manuals are really appreciated
Thanks, regards
Vincenzo

Hi
how can I perform login if my device is offline?
Once the device logs into the SUP once every-time thereafter the client app doesn't perform an online authentication.
The credentials are stored on the device securely and authenticated with the user supplied credentials. When the device is online it will perform the online authentication.
is the password used for login from device the same as the SAP system's?
You can have the same credentials on both the systems. The SAP connectivity credentials are however stored in SUP.
do SUP and SAP have to share the same user engine (i.e. LDAP)?
Yes currently SUP for development purposes has the openDS ldap service. but in production we can use the LDAP provider of your company.
Thanks

Error propagating servlet user to peer?

Hello,
We currently have a Windows 2003 Server 32bit running ColdFusion 8.01 with 3 instances named: cfusion, Instance1 and Instance2. Instance 1 and Instance 2 are clustered together and serving all our sites in IIS. We're hosting just over 200 sites with approx. 6-7 hits a second.
ColdFusion is running with all the latest hot fixes and patches. The JVM is version 1.6_24.
For a while now one of the instances in the cluster randomly locks up a few times a month, fails to return pages and has high cpu usage. We'd normally just restart the instance and things would return to normal. It's bad to ignore things but it's only recently I've had a chance to look into the cause of these lock ups.
Last night both the instances appeared to fail. We have an external monitor that hits our sites every 5 minutes to ensure they are still running.
Scanning through the JRun logs at about the time we received our first monitor warning there are a bunch of what appear to be propagation errors on both instances.
Logs from Instance1:
22/03 07:10:14 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:16 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:17 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:18 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:20 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:21 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:23 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:23 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:24 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:24 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:25 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:26 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:26 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:26 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:26 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:27 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:28 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:28 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:10:29 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketTimeoutException: Read timed out
22/03 07:17:43 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
Logs from Instance2:
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:40 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset by peer: socket write error
22/03 07:10:41 info Clusterable service JRunRMIBroker discovered ClusterManager on xxx.xxx.xxx.xxx:3862, cluster domain: cluster1 (Lookup Service's JINI-ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
22/03 07:10:42 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset
22/03 07:10:42 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.io.EOFException
22/03 07:10:42 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset
22/03 07:10:42 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.net.SocketException: Connection reset
22/03 07:10:42 warning Error propagating servlet user to peer: error during JRMP connection establishment; nested exception is:
    java.io.EOFException
22/03 07:10:43 error ROOT CAUSE:
java.lang.OutOfMemoryError: unable to create new native thread
    at java.lang.Thread.start0(Native Method)
    at java.lang.Thread.start(Thread.java:640)
I suspect it's a JVM memory issue, however I have no way of extracting or creating memory logs without bringing all our sites down again.
I only know the basics of how the JVM heap space works but my guess is that one of the instances can't create any more threads because the PermGen space has run out and it's killing the cluster.
Here's our current JVM settings: java.args=-server -Xmx768m -Xms768m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Dcoldfusion.fckupload=true -Dcoldfusion.rootDir={application.home}/
Has anyone come across this issue before or has any ideas on how to better debug the issue with minimal impact on uptime?

Well the classes should be in WEB-INF/classes, but I don't think that's your problem.
Getting an applet to connect to a db is notoriously difficult (so I've heard - I've never tried it), so having the applet talk to the servlet with the servlet in turn talking to the db is a good idea.
"i cant see the error message because it wont print in the VM,"
That doesn't sound right. What does your error handling code look like?
" MySQL it also has access permissions for some weird reason."
MySQL is set up so that user credentials are only valid from a specific host unless you explicitly tell it that a user can connect from anywhere. This is native to MySQL and has nothing to do with java or JDBC.
Most of the code you posted throws Exceptions. Are you catching them, and if so what did they say?

Helps for WLP9.2 in a cluster: deploy errors, propagation errors

I wrote a document for our portal project's production support that details how to fix several recuring problems with WLP9.2 (GA) in cluster. I'm sharing this with the community as a help.
Email me if you'd like updates or have additional scenarios / fixes or you'd like the word doc version.
Curt Smith, Atlanta WLP consultant, [email protected], put HELP WLP as a part of the subject please.
1     WLP 9.2 Environment
The cluster environment where these symptoms are frequently seen is described by the following:
1.     Solaris 9 on 4 cpu sparc boxes. 16Gb Ram. The VM is given ?Xmx1034m.
2.     Bea private patch: RSGT, fixed cluster deployments.
3.     Bea private patch: BG74, fixed session affinity, changed the session tracking cookie name back to the standard name: JSESSIONID.
4.     IBM UDB (DB2) using the Bea DB2 driver. FYI: the problems described below I don?t feel have any relationship to the DB used for a portal.
2     Common problems and their fixes
2.1     Failed deploy (Install) of a new portal application via the cluster console.
Problem symptoms:
After clicking Finish (or) Commit the console displays that there where errors. All errors require this procedure.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove file: <domain>/config/config.lok
b.     Edit file: <domain>/config/config.xml
c.     Remove all elements of: <app-deployment> ? </app-deployment>
d.     Start the Admin server
e.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
You can now use the console to Install your applications.
2.2     The portal throws framework / container exceptions on one managed instance.
Problem symptoms:
If you see exceptions from the classloader re a framework class not found, serialization failure or error etc. In general the symptom is that the container is not stable, running correctly, not making sense or your application works on one managed instance but not on the other.
Fix steps:
1.     Shut down the problem managed instance. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Perform these clean up steps on one or both managed instances:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
3.     The libraries and applications should auto deploy as the managed instance comes up. Once the managed instance goes into the running state, or you Resume into the running state. Your application should be accessible. Sometimes it takes a few seconds after going into the running state for all applications to be instantiated.
2.3     Content propagation fails on the commit step.
Problem symptoms:
In the log of the managed instance you specified in the propagation ant script you?ll see exceptions regarding not being able to create or instantiate a dynamic delegated role.
There is an underlying bug / robustness issue with WLP9.2 (GA) where periodically you can?t create delegated roles either with the PortalAdmin or via the propagation utility.
Important issue:
This procedure was supplied by Bea which will remove from the internal LDAP and the portal DB your custom / created roles. This will leave your cluster in the new installation state with just the default users and roles: weblogic and portaladmin. The implications are that you?ll have to boot your cluster with console user: weblogic / weblogic. You can then add back your secure console user/password but you?ll have to do this over and over as propagations fail. The observed failure rate is once every 2-3 weeks if you do propagations daily.
Note:
The following assumes that you left the default console user weblogic password to be the default password of: weblogic. The following procedure deletes the local LDAP but leaves the rows in the DB.users table including the SHA-1 hashed passwords. The following procedure should still work if you changed the password for weblogic, but it probably won?t work if you try to substitute your secure console user/pw because there will be no delegated authorization roles mapping to your custom console user. You might experiment with this scenario.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove directory: <domain>/servers/AdminServer/data/ldap
b.     Run this SQL script after you edit it for your schema:
delete from yourschema.P13N_DELEGATED_HIERARCHY;
delete from yourschema.P13N_ENTITLEMENT_POLICY;
delete from yourschema.P13N_ENTITLEMENT_RESOURCE;
delete from yourschema.P13N_ENTITLEMENT_ROLE;
delete from yourschema.P13N_ENTITLEMENT_APPLICATION;
commit;
c.     Start the Admin server
d.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/servers/<managed_name>
b.     rm ?rf data
This forces the re-down load of the LDAP directory.
c.     Start each managed server.
d.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
2.4     The enterprise portal DB fails and needs to be restored OR switch DB instances
Restoring a portal DB or switching existing DBs are similar scenarios. The issues that you?ll face with WLP9.2 since it now uses a JDBCauthenticator to authenticate and authorize the console / boot user you need to first be able to connect to the DB before the admin and managed instances can boot. If you haven?t properly encrypted the DB user?s password in the <domain>/config/jdbc/*.xml files, then you?ll not be able to boot the admin server since you won?t be able to create a JDBC connection to the DB. The boot messages are not clear as to what the failure is.
You?ll need to know an Admin role user and password that?s in the DB you?re wanting to connect to, to put into boot.properties and on the managed instances in their boot.properties or startManaged scripts. Don?t forget that the managed instances have local credentials which is new for 9.2. They are in the startManaged script in clear text or a local boot.properties.
Note:
The passwords in the DB are SHA-1 hashed and there is no SHA-1 hash generator tool so you can?t change a password via SQL, but you can move the password from one DB to another. This is possible because the domain encryption salt is not used to generate the SHA-1 string. As it turns out, the SHA-1 string is compatible with all 9.2 cluster domains. IE the domain DES3 salt has nothing to do with password verification. The same password SHA-1 string taken from different domains or even same domain but different users will be different, this is just a randomization put into the algorithm yet every domain will be able to validate the given password against the DB?s SHA-1 string. Because of this, I?ve not had any problem moving DB instances between clusters, especially if I?ve given up on security and use weblogic/weblogic as the console user and this user / pw is in every DB.
Steps:
The assumption for restoring a DB is that the DB has been restored but it?s an older version and doesn?t have the console user/pw that is in boot.properties. At this point swaping a DB is the same as restoring an old version of the portal DB.
1.     Edit the console user and password as clear text into: <domain>/servers/AdminServers/security/boot.properties
This is where you may give in and use weblogic/weblogic.
2.     Set the correct DB access password encryption in the jdbc/*.xml files.
a.     cd <domain>/bin
b.     . ./setDomainEnv.sh or if you?re on windows just run: setDomainEnv.cmd
c.     java weblogic.security.Encrypt <the_db_password>
d.     Edit the returned string into every <domain>/config/jdbc/*.xml
e.     Make sure the *.xml files point to the correct DB host, port, schema, DB name, DB user.
3.     Start the Admin server. I should come up. If it doesn?t it has to be not being able to create a connection to the DB, which depends on the *.xml having the correct user and DES-3 encrypted password.
4.     Edit the new console user/password on the managed instance bin/startManaged script or the local boot.properties.
5.     Start the managed instances.
2.5     Install patches on a host that does not have internet access
The short description is to run smart update on a host that does have internet access. Fetch out of the <domain>/utils/bsu/cache_dir     directory the downloaded patch jar and xml. Manually apply the patch to your non-internet accessible hosts.

I wrote a document for our portal project's production support that details how to fix several recuring problems with WLP9.2 (GA) in cluster. I'm sharing this with the community as a help.
Email me if you'd like updates or have additional scenarios / fixes or you'd like the word doc version.
Curt Smith, Atlanta WLP consultant, [email protected], put HELP WLP as a part of the subject please.
1     WLP 9.2 Environment
The cluster environment where these symptoms are frequently seen is described by the following:
1.     Solaris 9 on 4 cpu sparc boxes. 16Gb Ram. The VM is given ?Xmx1034m.
2.     Bea private patch: RSGT, fixed cluster deployments.
3.     Bea private patch: BG74, fixed session affinity, changed the session tracking cookie name back to the standard name: JSESSIONID.
4.     IBM UDB (DB2) using the Bea DB2 driver. FYI: the problems described below I don?t feel have any relationship to the DB used for a portal.
2     Common problems and their fixes
2.1     Failed deploy (Install) of a new portal application via the cluster console.
Problem symptoms:
After clicking Finish (or) Commit the console displays that there where errors. All errors require this procedure.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove file: <domain>/config/config.lok
b.     Edit file: <domain>/config/config.xml
c.     Remove all elements of: <app-deployment> ? </app-deployment>
d.     Start the Admin server
e.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
You can now use the console to Install your applications.
2.2     The portal throws framework / container exceptions on one managed instance.
Problem symptoms:
If you see exceptions from the classloader re a framework class not found, serialization failure or error etc. In general the symptom is that the container is not stable, running correctly, not making sense or your application works on one managed instance but not on the other.
Fix steps:
1.     Shut down the problem managed instance. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Perform these clean up steps on one or both managed instances:
a.     cd <domain>/config
b.     rm ?rf *
This forces the re-down load of the cleaned up config.xml.
c.     cd <domain>/servers/<managed_name>
d.     rm ?rf tmp cache stage data
This cleans up stale or jammed sideways deploys. Be sure to delete all three directorys: tmp, cache, stage and data.
e.     Start each managed server.
f.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
3.     The libraries and applications should auto deploy as the managed instance comes up. Once the managed instance goes into the running state, or you Resume into the running state. Your application should be accessible. Sometimes it takes a few seconds after going into the running state for all applications to be instantiated.
2.3     Content propagation fails on the commit step.
Problem symptoms:
In the log of the managed instance you specified in the propagation ant script you?ll see exceptions regarding not being able to create or instantiate a dynamic delegated role.
There is an underlying bug / robustness issue with WLP9.2 (GA) where periodically you can?t create delegated roles either with the PortalAdmin or via the propagation utility.
Important issue:
This procedure was supplied by Bea which will remove from the internal LDAP and the portal DB your custom / created roles. This will leave your cluster in the new installation state with just the default users and roles: weblogic and portaladmin. The implications are that you?ll have to boot your cluster with console user: weblogic / weblogic. You can then add back your secure console user/password but you?ll have to do this over and over as propagations fail. The observed failure rate is once every 2-3 weeks if you do propagations daily.
Note:
The following assumes that you left the default console user weblogic password to be the default password of: weblogic. The following procedure deletes the local LDAP but leaves the rows in the DB.users table including the SHA-1 hashed passwords. The following procedure should still work if you changed the password for weblogic, but it probably won?t work if you try to substitute your secure console user/pw because there will be no delegated authorization roles mapping to your custom console user. You might experiment with this scenario.
Fix steps:
1.     Shut down the whole cluster. Using Bea?s shutdown script takes too long, or doesn?t work if the Admin is down or hung.
a.     Find the PID to kill: lsof ?C | grep <listen port number>
b.     kill <pid>
c.     Run kill again and if the pid is still running then do: kill -9 <pid>
2.     Admin server:
a.     Remove directory: <domain>/servers/AdminServer/data/ldap
b.     Run this SQL script after you edit it for your schema:
delete from yourschema.P13N_DELEGATED_HIERARCHY;
delete from yourschema.P13N_ENTITLEMENT_POLICY;
delete from yourschema.P13N_ENTITLEMENT_RESOURCE;
delete from yourschema.P13N_ENTITLEMENT_ROLE;
delete from yourschema.P13N_ENTITLEMENT_APPLICATION;
commit;
c.     Start the Admin server
d.     Make sure it comes up in the running state. Use the console: servers ? admin ? control - resume if needed.
3.     Both Managed servers:
a.     cd <domain>/servers/<managed_name>
b.     rm ?rf data
This forces the re-down load of the LDAP directory.
c.     Start each managed server.
d.     Make sure the managed instance comes up in the running state and not admin. Go to server-<instance>-control-Resume to set the run state to running.
2.4     The enterprise portal DB fails and needs to be restored OR switch DB instances
Restoring a portal DB or switching existing DBs are similar scenarios. The issues that you?ll face with WLP9.2 since it now uses a JDBCauthenticator to authenticate and authorize the console / boot user you need to first be able to connect to the DB before the admin and managed instances can boot. If you haven?t properly encrypted the DB user?s password in the <domain>/config/jdbc/*.xml files, then you?ll not be able to boot the admin server since you won?t be able to create a JDBC connection to the DB. The boot messages are not clear as to what the failure is.
You?ll need to know an Admin role user and password that?s in the DB you?re wanting to connect to, to put into boot.properties and on the managed instances in their boot.properties or startManaged scripts. Don?t forget that the managed instances have local credentials which is new for 9.2. They are in the startManaged script in clear text or a local boot.properties.
Note:
The passwords in the DB are SHA-1 hashed and there is no SHA-1 hash generator tool so you can?t change a password via SQL, but you can move the password from one DB to another. This is possible because the domain encryption salt is not used to generate the SHA-1 string. As it turns out, the SHA-1 string is compatible with all 9.2 cluster domains. IE the domain DES3 salt has nothing to do with password verification. The same password SHA-1 string taken from different domains or even same domain but different users will be different, this is just a randomization put into the algorithm yet every domain will be able to validate the given password against the DB?s SHA-1 string. Because of this, I?ve not had any problem moving DB instances between clusters, especially if I?ve given up on security and use weblogic/weblogic as the console user and this user / pw is in every DB.
Steps:
The assumption for restoring a DB is that the DB has been restored but it?s an older version and doesn?t have the console user/pw that is in boot.properties. At this point swaping a DB is the same as restoring an old version of the portal DB.
1.     Edit the console user and password as clear text into: <domain>/servers/AdminServers/security/boot.properties
This is where you may give in and use weblogic/weblogic.
2.     Set the correct DB access password encryption in the jdbc/*.xml files.
a.     cd <domain>/bin
b.     . ./setDomainEnv.sh or if you?re on windows just run: setDomainEnv.cmd
c.     java weblogic.security.Encrypt <the_db_password>
d.     Edit the returned string into every <domain>/config/jdbc/*.xml
e.     Make sure the *.xml files point to the correct DB host, port, schema, DB name, DB user.
3.     Start the Admin server. I should come up. If it doesn?t it has to be not being able to create a connection to the DB, which depends on the *.xml having the correct user and DES-3 encrypted password.
4.     Edit the new console user/password on the managed instance bin/startManaged script or the local boot.properties.
5.     Start the managed instances.
2.5     Install patches on a host that does not have internet access
The short description is to run smart update on a host that does have internet access. Fetch out of the <domain>/utils/bsu/cache_dir     directory the downloaded patch jar and xml. Manually apply the patch to your non-internet accessible hosts.

"Multi-level error propagation carried out" in SCM 5.0

When I use the SNP PPM Generation With Lot Size Margin function in SCM 5.0, I got the following error:
Multi-level error propagation carried out
Message no. /SAPAPO/OM242
Could you please give me this help?
Thanks,
Lian

Hi,
Thank you for the information, but the problem is still there though I de-activated all user-exits...
I also saw the following error:
Invalid planning version
Message no. /SAPAPO/OM015
Thanks,
Lian

Multi-level error propagation carried out Error in APO

Dear Experts,
We had developed a custom program that is same as /sapapo/rrp3 report, but the issue is when we use planning version other then 000 the custom program is giving the error ""Multi-level error propagation carried out"" but the RRP3 report works fine with all the planning versions.
Please help to find the cause and to solve the issue.
Thanks.
Regards
Abhinav Nallani.

Dear Arek,
The problem is not yet resolved . we have raised an OSS note for the same.
as the relevant notes are already implemented in our case.
regards
Kiran

OSB Error propagation not propagating the original error

Hi,
I'm having trouble with understanding how to propagate error from inner to outer flow.
This is the scenario:
I have a flow listening on MQ queue, and in turn performs callouts to 3 inner flow's (protocol is local).
Inside the inner flows there is no error handler, and all the handling is performed at the outer flow.
The problem is that the error that is being caught is not the one I throw, instead I get a general BEA-380000 error.
(when I put an error handler at the inner flow and print $fault I see the real error).
Also I cannot put any "reply" operations inside any error handler because this will commit the XA transaction, and will prevent the message from going to backout queue - which I need to happen.
How can I make the error propagate correctly?

that's because the service error handler will wrap the fault in his own format
so in each service error handler you need to recreate the soap fault with the error stack, and reply that back to the calling service, otherwise you will loose the error details already in the proxy service in which the fault occures.
propagating the error without build the logic in each proxy service won't work if you ask me (and there also isn't a simple checkbox to enable anything on this)

Error "Multi-level error propagation carried out" when I run a report

Hi All,
When I run the report /SAPAPO/CDPS_REPT - Order and Resource Reporting with the below criteria I getting error "Multi-level error propagation carried out"
Planning Version - Simulation Version XXX
Evaluation Start - 05/03/2011
Evaluation End - 12/31/2013
Evaluation List - Extended Operation List
I do not get error when I run the report with selection as Active version 000 and Evaluation List as Order List, Operation List.
I have tried by ruuning Live cache consistancy check, but the issue is not fixed
Please help me to resolve this issue
Thanks & Regards,
Rajkumar

Hi Jack,
Please do post the server log file here so that we can try and find a solution for the problem you are facing.
I had a problem a while ago with the app server too. While trying to run an application, after a few times, it would give me an error message saying the Application Server cannot be started. I rebooted my machine and thankfully it worked again. Just try this too and see if it works.
If it doesnt we can go through the server log and try to identify the cause of the problem.
Cheers :-)

Error propagation with ANT

Hello, I have done a merge with 2 inventories, the first is from my local server with an EAR, the second is from other server (it was charged with a DUMP). The problem is at the propagation moment (by ANT), it throws errors like the following.
<11-01-2012 11:11:53 AM CLST> <Error><InventoryServices> <BEA-000000> <Unable to create inventory node [Application:portalservices:PortalMovistarWeb.WebApp:PortalMovistarWeb.Library:PortalMovistar_portals_PT_PortalMovistar_portal_book_1.Book:PortalMovistar_portals_PT_PortalMovistar_portal_book_1.Localization] because parent node [PortalMovistar_portals_PT_PortalMovistar_portal_book_1.Book] was notfound.>
<11-01-2012 11:11:53 AM CLST> <Error> <InventoryServices> <BEA-000000> <The TOCImporter could not create inventory node[PortalMovistar_portals_PT_PortalMovistar_portal_book_1.Localization] of type [PF_LOC_NODE].>
ERROR (11-01-2012 10:58:46 AM CLST):[Application:portalservices:PortalMovistarWeb.WebApp:PortalMovistarWeb.Library:c.Book:PortalMovistar_Persona_IC_internetMovil.BookMember:PortalMovistar_Persona_IC_internetMovil.Book:PortalMovistar_Persona_IC_internetMovil_Contr.BookMember:PortalMovistar_Persona_IC_internetMovil_Contr.Page:PL_084_CM_ProductoInternetMovil_3.PageMember:PL_084_CM_ProductoInternetMovil_3.PortletInst] failed to [add]
I had never had this kind of error, I hope you can help me.
Thanks.

Propagation issues are difficult to diagnose. I would suggest opening up a Support ticket with Oracle to get help with your issue.
Brad

Error Propagation Doubt

Hi,
I work with WorkSpace Studio 1.1.
In our project we have a few proxies linked, and I'd like to know if it's possible to have an error generated in the "last" proxy not propagated to the others, from which the message came.
I'd like that the error generated in the PS4 was not propagated to the PS3,PS2 and PS1. Is that possible?
PS1-->PS2-->PS3-->PS4
Thanks

Yes, it's possible. Just add Error Handler to PS4 and use Resume action or Reply with success in it.
http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/modelingmessageflow.html#wp1125471

Propagation O8 - O10g

Similar Messages

Maybe you are looking for