EWT and Professional User Transaction

Hi
Can anyone let me know the basic difference between EWT and Professional User Transactions. Why do I always need to come to the start Menu and then proceed with EWT Transactions ?
I find a Service attached to EWT transactions. What is this for ?
Regards,
Murali.

Hi Murali,
Professional User Transactions are the standard transactions executed in the SAP system. An Easy Web Transaction is an ITS-based transaction, which can be executed only in the SAP GUI for HTML. You need to refer to an ITS service in order to use it. This Inernet service has the HTML templates ^ can be maintained in SE80.
~Suresh

Similar Messages

Difference between Professional User and Limited Professional User?

SAP Members.
Hi \ Salam,
I want to know the difference between a Professional User and a Limited Professional User. Why do we create them and what are the advantages of having them?
Your input will be highly appreciated.
Regards,
Mohammed Ali Khan.

Yup. It means, in Limited Professional, you can display posted documents, view reports etc. & can create/change through single transaction, e.g. FB60. It is generally provided to management/heads.
Professional license is a fully functional license. You can use any transaction no matter if its create, change or display
BR
PS: The thread is not related to ERP Financials/

Assign User Profiles and Web Interface Transactions to Users

Hi EM Gurus,
Has anyone worked with not standard scenarios in SCEM?
They are working well but I can't access them on interface web.
In selection page (search page after logon), where choose tracking scenarios, only standard scenarios appear although I have assigned both scenarios to the user and made same configuration; Assigned and Defined Web Interface Transactions, Configured Fields for User Profiles, Defined User Profiles, Assigned User Profiles and Web Interface Transactions to Users.
But only Standard Scenarios appear as choice of tracking scenarios that are displayed to the user as a dropdown box on the selection screen after logging on to the Web interface.
Has anyone accessed not standard scenarios on interface web??
Help, please!
Thanks a lot.
Rodrigo Freitas

Hello Rodrigo,
if you have assigned the scenarios to your user in transaction /SAPTRX/UCUSER you must go to the admin page and reload the profile manager.
/admin in the URL of the WCL instead /ehsearch.
Afterwards you should see them also in the drop-down box.
Best regards,
Steffen

SRM Post Installation - Webadmin and EBP users

Hello SRM gurus,
I am new to SDN but I am familiar with SAP Basis Administration. I have recently installed the SRM 5.0(NW04s). I configured the shopping cart link and the integrated ITS. I was asked to create userid for webadmin (who creates users through the browser). I searched through SDN but was not able to find it. Please let me know the procedure to get the webadmin and creation of EBP users. I appreciate your time and business. Thanks in advance. Waiting for your replies......
Raj

Hello Raj,
1. Create webadmin user in SU01 transaction, assign SAP_BBP_STAL_ADMINISTRATOR role
2. Go to USERS_GEN transaction and create user from existing SU01 user
3. Go to PPOMA_BBP transaction and search the created webadmin user, Select position level and check the ROLE attributes. If no ROLE attributes are maintained, add SAP_BBP_STAL_EMPLOYEE
4. logon to SRM with webadmin user
Regards,
Masa

Two phase commit and bean managed transactions

To all the Transaction GURUS!
          Hi guys (-and gals).
          I've been doing J2EE for quite a while, but today was my first at
          XA-Transactions and Bean Managed Transactions.
          Why am I doing this?
          ====================
          Well I have to be able to controll the transactionalbehaviour of my
          bean
          during runtime, since some bean calls would cause a transactional
          overflow due to the stress they would cause to the system, whereas
          smaller bean calls need to run in one transaction.
          -> Therefore I need Bean Managed Transactions
          Since the bean does a call on two Database Connections it has to use a
          XA-Transaction.
          -> Therefore I need XA-Transactions.
          Abstract
          ========
          - I just can't get a User TransAction into the right Status it stays
          in 'STATUS_NO_TRANSACTION' all the time
          - Therefore the SQL Commands can be comitted 'java.sql.SQLException:
          Does not support SQL execution with no global transaction'
          - Therefore I can't do a rollback 'java.lang.IllegalStateException:
          Transaction does not exist'
          - Therefore I wrote this mail.
          I don't want to be a smart-"ass" writing such a detailed and indepth
          mail. I just would like to show that I tried, and would like to have
          some replies from you guys.
          Below are my configurations, code and logfiles.
          Thanx for taking your time and hope that the other people may learn
          something as well.
          cu
          Stefan
          Scenario
          ========
          used Software
          Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
          Oracle 8.1.6 using the API-Version 8
          I configured the system as follows:
          (ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
          excerpt from:
          config.xml
          <JDBCConnectionPool CapacityIncrement="5"
          DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
          LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
          Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
          
          <JDBCTxDataSource EnableTwoPhaseCommit="true"
          JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
          PoolName="oraclePool" Targets="fbsserver"/>
          
          <JDBCConnectionPool CapacityIncrement="5"
          DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="Users" SupportsLocalTransaction="true"/>
          
          <JDBCTxDataSource EnableTwoPhaseCommit="true"
          JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
          Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
          
          ejb-jar.xml
          <ejb-jar>
               <enterprise-beans>
                    <session>
                         <ejb-name>TPCTestBean</ejb-name>
          <home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
          <remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
          <ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
                         <session-type>Stateless</session-type>
                         <transaction-type>Bean</transaction-type>
                    </session>
               </enterprise-beans>
               <assembly-descriptor/>
          </ejb-jar>
          
          weblogic-ejb-jar.xml
          <weblogic-ejb-jar>
               <weblogic-enterprise-bean>
                    <ejb-name>TPCTestBean</ejb-name>
                    <stateless-session-descriptor/>
                    <jndi-name>finstral/ejb/test_tpc</jndi-name>
               </weblogic-enterprise-bean>
          </weblogic-ejb-jar>
          
          BeanCode (from the implementingBeanClass:
          'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
          public void setupTables() throws RemoteException
          UserTransaction tx = getTransaction();
          //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
          some errorhandling
          log.info("Die Transaktion vor den Connections: "+tx.toString());
          //Sorry bout the German. You should get the Message though.
          log.info("Der Transaktionsstatus vor den Connections:
          "+transactionStatus(tx));
          Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
          //gets a Connection via a DataSourceName from the JNDI tree
          Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
          log.info("Die frische Connection conSecurity: "+conSecurity);
          log.info("Die frische Connection conContent: "+conContent);
          tearDownTable(conSecurity);
          //Does nothing special
          tearDownTable(conContent);
          log.info("Die Transaktion nach dem Teardown: "+tx.toString());
          log.info("Der Transaktionsstatus nach dem Teardown:
          "+transactionStatus(tx));
          Statement stmt = null;
          try
          stmt = conSecurity.createStatement();
          //Well its getting interesting now.....
          log.info("Die Transaktion vor dem createtable: "+tx.toString());
          log.info("Der Transaktionsstatus vor dem createtable:
          "+transactionStatus(tx));
          log.info("Die Connection conSecurity vor dem createtable:
          "+conSecurity);
          log.info("Die Connection conContent vor dem createtable:
          "+conContent);
          stmt.executeUpdate(CREATE_TABLE);
          //above is the row 91 -> throws: 'java.sql.SQLException: Does
          not support SQL execution with no global transaction'
          stmt.close();
          stmt = conContent.createStatement();
          stmt.executeUpdate(CREATE_TABLE);
          stmt.close();
          commitTransaction(tx);
          catch (SQLException sqle)
          log.error("Konnte kein table init machen", sqle);
          rollbackTransaction(tx);
          //The Code for this method is below
          throw new EJBException(sqle);
          finally
          closeConnection(conSecurity);
          closeConnection(conContent);
          protected void rollbackTransaction(UserTransaction tx)
          log.info("Der Transaktionsstatus vor dem Rollback:
          "+transactionStatus(tx));
          log.info("Die Transaktion vor dem Rollback: "+tx.toString());
          try
          tx.rollback();
          //above is row 200 -> throws: 'java.lang.IllegalStateException:
          Transaction does not exist'
          log.info("Der Transaktionsstatus nach dem Rollback:
          "+transactionStatus(tx));
          log.info("Die Transaktion nach dem Rollback: "+tx.toString());
          catch (Exception e)
          log.error("Konnte die Transaktion nicht backrollen.", e);
          throw new EJBException(e);
          Log Excerpt
          ===========
          INFO setupTables() (66) - Die Transaktion vor den Connections:
          [email protected]
          INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
          STATUS_NO_TRANSACTION
          INFO setupTables() (72) - Die frische Connection conSecurity:
          weblogic.jdbc.rmi.SerialConnection@7c6daa
          INFO setupTables() (73) - Die frische Connection conContent:
          weblogic.jdbc.rmi.SerialConnection@3b425
          INFO setupTables() (78) - Die Transaktion nach dem Teardown:
          [email protected]
          INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
          STATUS_NO_TRANSACTION
          INFO setupTables() (86) - Die Transaktion vor dem createtable:
          [email protected]
          INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
          STATUS_NO_TRANSACTION
          INFO setupTables() (88) - Die Connection conSecurity vor dem
          createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
          INFO setupTables() (89) - Die Connection conContent vor dem
          createtable: weblogic.jdbc.rmi.SerialConnection@3b425
          ERROR setupTables() (101) - Konnte kein table init machen
          java.sql.SQLException: Does not support SQL execution with no global
          transaction
               at
          weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
               at
          weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
               at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
               at
          weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.jav
          a:42)
               at
          weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
          a:91)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
          Impl.java:130)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
          anEOImpl.java:64)
               at
          de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
          mmitUnitTest.java:51)
               at
          org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
          tCase.java:297)
               at
          org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
          tTestCaller.java:148)
               at
          org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
          ler.java:199)
               at
          org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
          tRedirector.java:149)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
          java:213)
               at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
          etContext.java:1265)
               at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
          java:1631)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
          Rollback: STATUS_NO_TRANSACTION
          INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
          [email protected]
          ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
          backrollen.
          java.lang.IllegalStateException: Transaction does not exist
               at
          weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
          nManagerImpl.java:228)
               at
          weblogic.transaction.internal.TransactionManagerImpl.rollback(Transactio
          nManagerImpl.java:222)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TPC
          Bean.java:200)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.jav
          a:102)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBean
          Impl.java:130)
               at
          de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCBe
          anEOImpl.java:64)
               at
          de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseCo
          mmitUnitTest.java:51)
               at
          org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTes
          tCase.java:297)
               at
          org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servle
          tTestCaller.java:148)
               at
          org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCal
          ler.java:199)
               at
          org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTes
          tRedirector.java:149)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
               at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
               at
          weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
          java:213)
               at
          weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
          etContext.java:1265)
               at
          weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
          java:1631)
               at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
               at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          CONCLUSION
          ==========
          I'm going nuts.
          I just don't get it.
          The transaction is the same. I don't change the Connection. I start
          the Transaction at the beginning before I do anything!
          Please guys help me out.
          Thx alot.
          Stefan "it's three o'clock in the morning, my girlfriend left me, and
          my only friend is that stupid linux pinguine" Siprell
          Software-Development
          <<<<<<<<<<<<<<<<<<<<<<<<<<<
          <sitewaerts> GmbH
          Hebelstraße 15
          D-76131 Karlsruhe
          Tel: +49 (721) 920 918 22
          Fax: +49 (721) 920 918 29
          http://www.sitewaerts.de
          >>>>>>>>>>>>>>>>>>>>>>>>>>>


Hi Priscilla
          (did you ever see the movie ? :-))
          Well I moved away from the idea of using bean managed transaction. I'll
          be using Container Managed Transactions. To modify the
          transactionalbehaviour I'll write proxymethods which have certain
          different containermanaged transaction properties, but which all call
          the same private methods.
          But it works! Here is my experience:
          - I was doing a DDL statement: I was trying to create new Tables, which
          is a definite "no-go"
          - pay careful attention to:
          http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051405
                    and
          http://edocs.bea.com/wls/docs60/jta/trxejb.html#1051741
          and use these Settings for the Pool, don't ask me why, but it took me
          hours to find it out by myself:
               <JDBCConnectionPool CapacityIncrement="5"
          DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          Properties="user=xxx; password=xxx; server=xxx.xxx.xxx"
          RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          TestTableName="Users" SupportsLocalTransaction="true"/>
          where as the server (shown as: xxx.xxx.xxx) is the TNS Name of the
          Oracle Driver.
          It works great.
          Another thing you guys might want to do is write a simple StatelessSB
          which does JDBC calls and two different database Connections.
          Then write a UnitTest which calls this bean a couple hundred times (with
          the same transaction). Have one test do clean writes, and another which
          causes some SQL-Exception (too long Data Columns, or likewise).
          Always count the entries and see if everything worked out. We're using
          this SetupConstruction to test new combinations of AS(sorry Priscilla) /
          Database / Db-Drivers to have a "standard test".
          I know my two cents were uncalled for, but it might save you some
          time.....
          thanx for your help
          Stefan
          -----Ursprüngliche Nachricht-----
          Von: Priscilla Fung [mailto:[email protected]]
          Bereitgestellt: Donnerstag, 2. August 2001 21:42
          Bereitgestellt in: transaction
          Unterhaltung: Two phase commit and bean managed transactions
          Betreff: Re: Two phase commit and bean managed transactions
          Hi Stefan,
          Looks like you have not actually begun a transaction by calling
          UserTransaction.begin(),
          so your setupTables method is really executing with no transaction
          context.
          Priscilla
          Stefan Siprell <[email protected]> wrote:
          >To all the Transaction GURUS!
          >
          >Hi guys (-and gals).
          >I've been doing J2EE for quite a while, but today was my first at
          >XA-Transactions and Bean Managed Transactions.
          >
          >Why am I doing this?
          >====================
          >Well I have to be able to controll the transactionalbehaviour of my
          >bean
          >during runtime, since some bean calls would cause a transactional
          >overflow due to the stress they would cause to the system, whereas
          >smaller bean calls need to run in one transaction.
          >-> Therefore I need Bean Managed Transactions
          >Since the bean does a call on two Database Connections it has to use
          >a
          >XA-Transaction.
          >-> Therefore I need XA-Transactions.
          >
          >Abstract
          >========
          >- I just can't get a User TransAction into the right Status it stays
          >in 'STATUS_NO_TRANSACTION' all the time
          >- Therefore the SQL Commands can be comitted 'java.sql.SQLException:
          >Does not support SQL execution with no global transaction'
          >- Therefore I can't do a rollback 'java.lang.IllegalStateException:
          >Transaction does not exist'
          >- Therefore I wrote this mail.
          >
          >I don't want to be a smart-"ass" writing such a detailed and indepth
          >mail. I just would like to show that I tried, and would like to have
          >some replies from you guys.
          >
          >Below are my configurations, code and logfiles.
          >
          >Thanx for taking your time and hope that the other people may learn
          >something as well.
          >
          >cu
          >
          >Stefan
          >
          >
          >Scenario
          >========
          >
          >used Software
          >-------------
          >Bea Weblogic (WL) 6.0 SPx (not real sure which SP i have)
          >Oracle 8.1.6 using the API-Version 8
          >
          >
          >I configured the system as follows:
          >(ofcourse I 'xxx'ed out all of the confidential data, sorry guys;-))
          >excerpt from:
          >
          >config.xml
          >----------
          ><JDBCConnectionPool CapacityIncrement="5"
          >DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="2"
          >LoginDelaySeconds="1" MaxCapacity="5" Name="oraclePool"
          >Properties="user=xxx;password=xxx;dll=ocijdbc8;protocol=thin"
          >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          >TestTableName="languages" URL="jdbc:oracle:thin:@xxx:1521:xxx "/>
          >
          >
          >
          ><JDBCTxDataSource EnableTwoPhaseCommit="true"
          >JNDIName="finstral.datasource.fbs" Name="finstral Content Datasource"
          >PoolName="oraclePool" Targets="fbsserver"/>
          >
          >
          >
          ><JDBCConnectionPool CapacityIncrement="5"
          >DriverName="weblogic.jdbc.oci.xa.XADataSource" InitialCapacity="1"
          >LoginDelaySeconds="1" MaxCapacity="2" Name="oracleSecurityPool"
          >Properties="user=xxx;password=xxx;server=xxx.xxx.xxx"
          >RefreshMinutes="5" Targets="fbsserver" TestConnectionsOnRelease="true"
          >TestTableName="Users" SupportsLocalTransaction="true"/>
          >
          >
          >
          ><JDBCTxDataSource EnableTwoPhaseCommit="true"
          >JNDIName="finstral.datasource.fbssecurity" Name="finstral Security
          >Datasource" PoolName="oracleSecurityPool" Targets="fbsserver"/>
          >
          >
          >
          >
          >
          >ejb-jar.xml
          >-----------
          ><ejb-jar>
          >     <enterprise-beans>
          >          <session>
          >               <ejb-name>TPCTestBean</ejb-name>
          >
          ><home>de.sitewaerts.futuna.common.test.tpcbean.TPCHome</home>
          >
          ><remote>de.sitewaerts.futuna.common.test.tpcbean.TPC</remote>
          >
          ><ejb-class>de.sitewaerts.futuna.common.test.tpcbean.TPCBean</ejb-class>
          >               <session-type>Stateless</session-type>
          >               <transaction-type>Bean</transaction-type>
          >          </session>
          >     </enterprise-beans>
          >     <assembly-descriptor/>
          ></ejb-jar>
          >
          >
          >
          >weblogic-ejb-jar.xml
          >--------------------
          ><weblogic-ejb-jar>
          >     <weblogic-enterprise-bean>
          >          <ejb-name>TPCTestBean</ejb-name>
          >          <stateless-session-descriptor/>
          >          <jndi-name>finstral/ejb/test_tpc</jndi-name>
          >     </weblogic-enterprise-bean>
          ></weblogic-ejb-jar>
          >
          >
          >
          >BeanCode (from the implementingBeanClass:
          >'de.sitewaerts.futuna.common.test.tpcbean.TPCBean')
          >-----------------------------------------------------------------------
          >---------------------
          >
          > public void setupTables() throws RemoteException
          > {
          > UserTransaction tx = getTransaction();
          > //getTransaction calls: 'tx = sCtx.getUserTransaction()' and does
          >some errorhandling
          >
          > log.info("Die Transaktion vor den Connections: "+tx.toString());
          > //Sorry bout the German. You should get the Message though.
          > log.info("Der Transaktionsstatus vor den Connections:
          >"+transactionStatus(tx));
          >
          > Connection conSecurity = getConnection(DATASOURCE_SECURITY, tx);
          > //gets a Connection via a DataSourceName from the JNDI tree
          > Connection conContent = getConnection(DATASOURCE_CONTENT, tx);
          >
          > log.info("Die frische Connection conSecurity: "+conSecurity);
          > log.info("Die frische Connection conContent: "+conContent);
          >
          > tearDownTable(conSecurity);
          > //Does nothing special
          > tearDownTable(conContent);
          >
          > log.info("Die Transaktion nach dem Teardown: "+tx.toString());
          > log.info("Der Transaktionsstatus nach dem Teardown:
          >"+transactionStatus(tx));
          >
          > Statement stmt = null;
          > try
          > {
          > stmt = conSecurity.createStatement();
          > //Well its getting interesting now.....
          >
          > log.info("Die Transaktion vor dem createtable: "+tx.toString());
          > log.info("Der Transaktionsstatus vor dem createtable:
          >"+transactionStatus(tx));
          > log.info("Die Connection conSecurity vor dem createtable:
          >"+conSecurity);
          > log.info("Die Connection conContent vor dem createtable:
          >"+conContent);
          >
          > stmt.executeUpdate(CREATE_TABLE);
          > //above is the row 91 -> throws: 'java.sql.SQLException: Does
          >not support SQL execution with no global transaction'
          >
          > stmt.close();
          >
          > stmt = conContent.createStatement();
          > stmt.executeUpdate(CREATE_TABLE);
          > stmt.close();
          > commitTransaction(tx);
          > }
          > catch (SQLException sqle)
          > {
          > log.error("Konnte kein table init machen", sqle);
          > rollbackTransaction(tx);
          > //The Code for this method is below
          > throw new EJBException(sqle);
          > }
          > finally
          > {
          > closeConnection(conSecurity);
          > closeConnection(conContent);
          > }
          > }
          >
          > protected void rollbackTransaction(UserTransaction tx)
          > {
          > log.info("Der Transaktionsstatus vor dem Rollback:
          >"+transactionStatus(tx));
          > log.info("Die Transaktion vor dem Rollback: "+tx.toString());
          > try
          > {
          > tx.rollback();
          > //above is row 200 -> throws: 'java.lang.IllegalStateException:
          >Transaction does not exist'
          > log.info("Der Transaktionsstatus nach dem Rollback:
          >"+transactionStatus(tx));
          > log.info("Die Transaktion nach dem Rollback: "+tx.toString());
          > }
          > catch (Exception e)
          > {
          > log.error("Konnte die Transaktion nicht backrollen.", e);
          > throw new EJBException(e);
          > }
          > }
          >
          >Log Excerpt
          >===========
          >INFO setupTables() (66) - Die Transaktion vor den Connections:
          >[email protected]
          >INFO setupTables() (67) - Der Transaktionsstatus vor den Connections:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (72) - Die frische Connection conSecurity:
          >weblogic.jdbc.rmi.SerialConnection@7c6daa
          >INFO setupTables() (73) - Die frische Connection conContent:
          >weblogic.jdbc.rmi.SerialConnection@3b425
          >INFO setupTables() (78) - Die Transaktion nach dem Teardown:
          >[email protected]
          >INFO setupTables() (79) - Der Transaktionsstatus nach dem Teardown:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (86) - Die Transaktion vor dem createtable:
          >[email protected]
          >INFO setupTables() (87) - Der Transaktionsstatus vor dem createtable:
          >STATUS_NO_TRANSACTION
          >INFO setupTables() (88) - Die Connection conSecurity vor dem
          >createtable: weblogic.jdbc.rmi.SerialConnection@7c6daa
          >INFO setupTables() (89) - Die Connection conContent vor dem
          >createtable: weblogic.jdbc.rmi.SerialConnection@3b425
          >ERROR setupTables() (101) - Konnte kein table init machen
          >java.sql.SQLException: Does not support SQL execution with no global
          >transaction
          >     at
          >weblogic.jdbc.oci.xa.XAConnection.beforeExecute(XAConnection.java:137)
          >     at
          >weblogic.jdbc.oci.xa.Statement.executeUpdate(Statement.java:112)
          >     at weblogic.jdbc.jta.Statement.executeUpdate(Statement.java:185)
          >     at
          >weblogic.jdbc.rmi.internal.StatementImpl.executeUpdate(StatementImpl.ja
          v
          >a:42)
          >     at
          >weblogic.jdbc.rmi.SerialStatement.executeUpdate(SerialStatement.java:54
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
          v
          >a:91)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
          n
          >Impl.java:130)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
          e
          >anEOImpl.java:64)
          >     at
          >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
          o
          >mmitUnitTest.java:51)
          >     at
          >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
          s
          >tCase.java:297)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
          e
          >tTestCaller.java:148)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
          l
          >ler.java:199)
          >     at
          >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
          s
          >tRedirector.java:149)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >     at
          >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
          >java:213)
          >     at
          >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
          l
          >etContext.java:1265)
          >     at
          >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
          >java:1631)
          >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >INFO rollbackTransaction() (196) - Der Transaktionsstatus vor dem
          >Rollback: STATUS_NO_TRANSACTION
          >INFO rollbackTransaction() (197) - Die Transaktion vor dem Rollback:
          >[email protected]
          >ERROR rollbackTransaction() (206) - Konnte die Transaktion nicht
          >backrollen.
          >java.lang.IllegalStateException: Transaction does not exist
          >     at
          >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
          o
          >nManagerImpl.java:228)
          >     at
          >weblogic.transaction.internal.TransactionManagerImpl.rollback(Transacti
          o
          >nManagerImpl.java:222)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.rollbackTransaction(TP
          C
          >Bean.java:200)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBean.setupTables(TPCBean.ja
          v
          >a:102)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanImpl.setupTables(TPCBea
          n
          >Impl.java:130)
          >     at
          >de.sitewaerts.futuna.common.test.tpcbean.TPCBeanEOImpl.setupTables(TPCB
          e
          >anEOImpl.java:64)
          >     at
          >de.sitewaerts.futuna.common.test.TwoPhaseCommitUnitTest.setUp(TwoPhaseC
          o
          >mmitUnitTest.java:51)
          >     at
          >org.apache.commons.cactus.AbstractTestCase.runBareServerTest(AbstractTe
          s
          >tCase.java:297)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.callTestMethod(Servl
          e
          >tTestCaller.java:148)
          >     at
          >org.apache.commons.cactus.server.ServletTestCaller.doTest(ServletTestCa
          l
          >ler.java:199)
          >     at
          >org.apache.commons.cactus.server.ServletTestRedirector.doPost(ServletTe
          s
          >tRedirector.java:149)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
          >     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
          >     at
          >weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl
          >java:213)
          >     at
          >weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServ
          l
          >etContext.java:1265)
          >     at
          >weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl
          >java:1631)
          >     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
          >     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
          >
          >
          >CONCLUSION
          >==========
          >I'm going nuts.
          >I just don't get it.
          >The transaction is the same. I don't change the Connection. I start
          >the Transaction at the beginning before I do anything!
          >Please guys help me out.
          >Thx alot.
          >
          >Stefan "it's three o'clock in the morning, my girlfriend left me, and
          >my only friend is that stupid linux pinguine" Siprell
          >Software-Development
          ><<<<<<<<<<<<<<<<<<<<<<<<<<<
          ><sitewaerts> GmbH
          >Hebelstraße 15
          >D-76131 Karlsruhe
          >
          >Tel: +49 (721) 920 918 22
          >Fax: +49 (721) 920 918 29
          >http://www.sitewaerts.de
          >>>>>>>>>>>>>>>>>>>>>>>>>>>>
          >
          >
          >

Error occurred during the rollback using User Transaction

Dear all,
I am trying to insert a record in SQL Server, using a session bean. In session bean , I started the user transaction, then get the JDBC connection (Using JDBCTxDataSource) and query is executed for inserting a record. If any SQL exception occurred during the insertion, I catch the exception, then I closed the connection and I rollback the transaction . If exception occurs, inserted data is rolled back and same the time it is giving a weblogic error. Please help me in solving this error.
Error is,
java.sql.SQLException: The transaction is no longer active - status: 'Rolling Back. [Reason=Unknown]'. No further JDBC access is allowed within this transaction.
at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:155)
at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:164)
at weblogic.jdbc.wrapper.Statement.checkStatement(Statement.java:234)
at weblogic.jdbc.wrapper.Statement.cancel(Statement.java:368)
at weblogic.jdbc.wrapper.Connection.cancelAllStatements(Connection.java:292)
at weblogic.jdbc.wrapper.JTSConnection.internalRollback(JTSConnection.java:388)
at weblogic.jdbc.wrapper.JTSXAResourceImpl.rollback(JTSXAResourceImpl.java:75)
at weblogic.transaction.internal.XAServerResourceInfo.rollback(XAServerResourceInfo.java:1317)
at weblogic.transaction.internal.XAServerResourceInfo.rollback(XAServerResourceInfo.java:650)
at weblogic.transaction.internal.ServerSCInfo.startRollback(ServerSCInfo.java:729)
at weblogic.transaction.internal.ServerTransactionImpl.localRollback(ServerTransactionImpl.java:1829)
at weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTransactionImpl.java:2511)
at weblogic.transaction.internal.ServerTransactionImpl.internalRollback(ServerTransactionImpl.java:383)
at weblogic.transaction.internal.ServerTransactionImpl.rollback(ServerTransactionImpl.java:362)
at weblogic.transaction.internal.TransactionManagerImpl.rollback(TransactionManagerImpl.java:320)
at com.bis.dbservices.entitydao.BISEntityBean.createEntity(BISEntityBean.java:308)
at com.bis.dbservices.entitydao.BISEntityBean_wo2ue8_EOImpl.createEntity(BISEntityBean_wo2ue8_EOImpl.java:592)
Thanks
Maria Singh

Hi. That is a bug. I have the fix for it.
Contact support and ask for a fix for CR211812.
Joe
Raja M wrote:
Joe,
In CR196085, it is mentioned that transaction problem is solved in Weblogic 8.1, SP4
So, I installed weblogic 8.1 SP4. But now, I am getting different error. Please help me.
The stactrace is as follows,
java.lang.NullPointerException
at weblogic.jdbc.wrapper.Statement.cancel(Statement.java:426)
at weblogic.jdbc.wrapper.Connection.cancelAllStatements(Connection.java:301)
at weblogic.jdbc.wrapper.JTSConnection.internalRollback(JTSConnection.java:453)
at weblogic.jdbc.wrapper.JTSXAResourceImpl.rollback(JTSXAResourceImpl.java:75)
at weblogic.transaction.internal.XAServerResourceInfo.rollback(XAServerResourceInfo.java:135
8)
at weblogic.transaction.internal.XAServerResourceInfo.rollback(XAServerResourceInfo.java:687
at weblogic.transaction.internal.ServerSCInfo.startRollback(ServerSCInfo.java:729)
at weblogic.transaction.internal.ServerTransactionImpl.localRollback(ServerTransactionImpl.j
ava:1909)
at weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTransactionImpl.
java:2592)
at weblogic.transaction.internal.ServerTransactionImpl.internalRollback(ServerTransactionImp
l.java:385)
at weblogic.transaction.internal.ServerTransactionImpl.rollback(ServerTransactionImpl.java:3
64)
at weblogic.transaction.internal.TransactionManagerImpl.rollback(TransactionManagerImpl.java
:320)
at com.bis.dbservices.entitydao.BISEntityBean.createEntity(BISEntityBean.java:308)
at com.bis.dbservices.entitydao.BISEntityBean_wo2ue8_EOImpl.createEntity(BISEntityBean_wo2ue
8_EOImpl.java:536)
at com.bis.dbservices.entitydao.BISEntityBean_wo2ue8_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:166)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:290)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:247)
at com.bis.dbservices.entitydao.BISEntityBean_wo2ue8_EOImpl_814_WLStub.createEntity(Unknown
Source)
at com.bis.dbservices.entitydao.EntityHandler.createEntity(EntityHandler.java:106)
at com.bis.quickfindui.QuickFindServlet.doGet(QuickFindServlet.java:1387)
at com.bis.quickfindui.QuickFindServlet.service(QuickFindServlet.java:553)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.jav
a:1006)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletC
ontext.java:6718)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:37
64)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2644)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)

Is it possible to lock and unlock a transaction?

Hi SDN,
Is it possible to lock and unlock a standard transaction( for eg VA02 ) through my program?( i am creating a customized version of standard transaction ) I want to lock the transaction for my user-id and then i will update the values in that transaction and finally i will unlock it.
I got the FM for locking at the database level.is there is any FM to lock and unlock the transaction?

Hi,
It may not be the best way, but maybe you could use the functionality behind transaction code SM01. Here you can lock/unlock the transaction code. If you look at the program, all it is really doing is updating table TSTC field CINFO. CINFO = 80 when unlocked, CINFO = A0 when locked. You could just update the field accordingly and then call this function module right after.
* For locking
CALL FUNCTION 'RSAU_WRITE_SM01_LOG'
EXPORTING
    TCODE = TSTC-TCODE
    LOCK = 'X'.
* For unlocking
CALL FUNCTION 'RSAU_WRITE_SM01_LOG'
EXPORTING
    TCODE = TSTC-TCODE
    UNLOCK = 'X'.
Regards,
Ferry Lianto

Obsolete and batch users can receive work items

Dear Experts,
Currently, we have found a problem that obsolete and batch users can receive work items by manual forwarding from someone. The roles and responsibilities of obsolete users were removed and users have been locked. For Batchuser, it's only created for some certain job with limited roles.
Could you help advise if this's a behavior of workflow or it's from some authorization problem? We have concern for business impact since no one is really handling work items and important messages are out of sight.
Thank you very much in advance.
Regards, Kae

Hello,
This is standard behaviour. It is even possible to send work items to users who do not yet exist (e.g. someone who is due to join the company).
The easiest way to workaround is to set up a substitution for any users that get locked and for background users. Personal substitutes can be maintained directly in table HRUS_D2, you could possibly write your own maintenance transaction for this if it is to be an ongoing issue.
Hope that helps,
Mike
Message was edited by:
Mike Pokraka

Appraisal - tcode access to core and end users

Hi Experts,
Please let me know which transaction code access is to be given to Super Users, Core Users and End users from the list below.
And also, Please let me know if I have missed out any transaction codes related to Appraisals.
T codes for PMS Basic Setting
OOHAP_BASIC           Basic Appraisal Template Settings
OOHAP_CATEGORY           Appraisal Category Settings
OOHAP_CAT_GROUP     Category Group Settings
OOHAP_SETTINGS_PA    PA: Settings
OOHAP_VALUE_TYPE     Standard Value Lists
T codes for PMS Process
PHAP_ADMIN     Administrator - Appraisal Document
PHAP_CATALOG     Appraisal Template Catalog
PHAP_CHANGE     Change Appraisal Document
PHAP_CREATE     Create Appraisal
PHAP_PREPARE     Prepare Appraisal Documents
PHAP_SEARCH     Evaluate Appraisal Document
This is very urgent..Your immediate response is highly appreciated.
Thanks!

Hi,
End users are authorized with
PHAP_CHANGE Change Appraisal Document
PHAP_CREATE Create Appraisal
PHAP_PREPARE Prepare Appraisal Documents
the T.codes
where they can prepare appraisals, if mistakenly entered wrong appraiser or appraisee they can edit
For other activities administrators must have autorization
Regards
Ratan Puli

COM dlls in the Standard and Professional Editions of Crystal Reports

Post Author: enz0
CA Forum: Deployment
Hi.
Do the Standard and Professional editions of Crystal reports install all the com dlls?
thanks

Hi,
The crystal reports trainign for SAP Business One is designed for partners and customers and provided for free to them.
It's not available to non-customers. You will need to have a login to the partner or customer portal to use it.
Alternatively you can use the regular Crystal Reports training resources or available books to get yourself skilled for Crystal Reports. Being able to work with Crystal Reports is 90% of the work where as the SAP Business One specific's are in the area of ....
- Release 8.8: the datasource connections; working with variables in the report; intergration and distribution of reports
- Release 2007: linking the reports into the SAP Business One menu and making them secured available to the end users.
Best regards,
Peter

Home Interface Load Balancing with user transactions

Hi
          Im running the following Client scenario:
          * gets initial context
          * lookup for Home Interface.
          * save the Home Interface.
          * Begin User Transaction
          * Home.findByPrimaryKey(pk)
          * activate some business method
          * Commit transaction.
          * close context
          now repeat but use the saved home interface
          * gets initial context
          * get saved Home Interface.
          * Begin User Transaction
          * Home.findByPrimaryKey(pk)
          * activate some business method
          * Commit transaction.
          * close context
          It seems that once i use the Home finder under a transaction the home
          interface will stick to the first server and load balancing won't work
          (doesn't matter if its round-robin or random).
          that means that in both cases the EjbObject i use is on the same server.
          please correct me if im wrong.
          but if im right is this a weblogic bug? or maybe a feature?
          thanks
          Dror Last


You will find that most engineers at BEA strong recommend NOT using UserTxns, unless you've got some
          complex nest transaction modeling that can't be done with BMT.
          From your case, it looks as if you should use a Session-bean facade between your servlets and entity
          beans; this way you set the session bean BMT attribute to whatever you wanted using
          UserTransaction; try this out and see what happens with load-balancing... we use BMT in clustered
          servers and load-balancing works great.
          Gene
          "Dror Last" <[email protected]> wrote in message news:[email protected]...
          > Im using Weblogic 5.1 / SP8
          >
          > <home-is-clusterable> set to TRUE on all beans.....
          >
          >
          > I have a big Question Mark if weblogic clustering does have load balancing
          > while the client (Servlet Engine in my case) Uses User Transactions.
          >
          > thanks
          > Dror Last
          >
          >
          > "Gene Chuang" <[email protected]> wrote in message
          > news:[email protected]...
          > > What WL version are u using, and what do you have <home-is-clusterable>
          > set to?
          > >
          > > Gene
          > >
          > > "Dror Last" <[email protected]> wrote in message
          > news:[email protected]...
          > > > Hi
          > > >
          > > > Im running the following Client scenario:
          > > >
          > > > * gets initial context
          > > > * lookup for Home Interface.
          > > > * save the Home Interface.
          > > > * Begin User Transaction
          > > > * Home.findByPrimaryKey(pk)
          > > > * activate some business method
          > > > * Commit transaction.
          > > > * close context
          > > >
          > > > now repeat but use the saved home interface
          > > >
          > > > * gets initial context
          > > > * get saved Home Interface.
          > > > * Begin User Transaction
          > > > * Home.findByPrimaryKey(pk)
          > > > * activate some business method
          > > > * Commit transaction.
          > > > * close context
          > > >
          > > > It seems that once i use the Home finder under a transaction the home
          > > > interface will stick to the first server and load balancing won't work
          > > > (doesn't matter if its round-robin or random).
          > > >
          > > > that means that in both cases the EjbObject i use is on the same server.
          > > >
          > > > please correct me if im wrong.
          > > >
          > > > but if im right is this a weblogic bug? or maybe a feature?
          > > >
          > > > thanks
          > > > Dror Last
          > > >
          > > >
          > >
          > >
          >
          >

40655SQL error forced rollback: clear form and re-enter transaction

Hello ,
I have ORACLE 10G & Forms 6i on Windows server 2008 . When I open the forms for some work , it give me error in few minis.
FRM-40655: SQL error forced rollback: clear form and re-enter transaction.
I have not done anything unusual in form design. it was working properly from a long time.
Yesterday i set the default profile to idle_time = 20. Will that make any problem ???
I checked my Alert Log but no sign of any deadlock in it, or any other unusual activity ....
What is the solution ???
Thanks in advance ..
Edited by: DBA4 on Jul 17, 2010 11:43 AM

Thanks for the reply ......
I would like to tell some more details here.
Previously i wanted to set an IDLE_TIME limit of 20 mins for all users in the DEFAULT profile.
So i did the process for the same...
I set the resource_limit parameter to true & then altered the default profile's idle_time to 20.
soon after that all the users who were accessing the database got this error while working ....
SQL error forced rollback: clear form and re-enter transaction.
In our case one user is opened & accessed by many people.
for ex - a user called UERP is open at Machine1 & also at Machine2. So at a time a single user can be opened at multiple sessions.
can this be the problem for forced rollback ???
My basic need is , i want to set the IDLE_TIME to 20 min but users should not face forced rollback error ????
what should i do ???
thanks in advance ....
Edited by: DBA4 on Jul 19, 2010 2:28 PM

FRM-40655: SQL error forced rollback: clear form and re-enter transaction.

Hello ,
I have ORACLE 10G & Forms 6i on Windows server 2008 . When I open the forms for some work , it give me error in few minis.
FRM-40655: SQL error forced rollback: clear form and re-enter transaction.
I have not done anything unusual in form design. it was working properly from a long time.
Yesterday i set the default profile to idle_time = 20. Will that make any problem ???
I checked my Alert Log but no sign of any deadlock in it, or any other unusual activity ....
What is the solution ???
Thanks in advance ..

This happens due to dead lock situation
To avoid this problem, add NOWAIT option to the UPDATE and DELETE statements, which returns ORA-00054 error, trap this error and display user defined message like 'The record is being accessed and try after some time'.
This even improves the performance
because no process waits for the locks preventing dead locks.
If it is due to the UPDATE's or DELETE's with base table blocks in the form, in the PRE-UPDATE and PRE-DELETE triggers write SELECT statements to select the particular row with FOR UPDATE NO WAIT option. Handle by trapping the ORA-00054 error

Getting eroor while copying and deleting user

Hi All,
I am unable to copy and delete users from one client, we are in ecc6.0. i am getting the following error while copying and deleting. the error is
NUMBER_GET_NEXT AENDBELEG INTERVAL_MISSING.
Please help me in this regard,
thanks,
praveen

Hi Praveen,
Implement the program correction to ensure that the system issues the correct error message.
Manually create the missing interval.
You can use error message CD 121 to enable you to identify the error more accurately. Depending on the additional information, the status is as follows:
OBJECT_MISSING : The entire AENDBELEG number range object is missing and must be created.
INTERVAL_MISSING: Number range interval 01 is missing and must be created.
INTERVAL_NOT_INTERNAL: The definition of number range interval 01 is incorrectly set to 'external number assignment'. Delete the 'external' selection in the interval definition.
Check the definition of the AENDBELEG number range object in transaction SNRO:
Object name:   AENDBELEG
Short text:    Change documents
Long text:     Number Ranges for Change Documents
To-year flag:                        Do not select
Number length domain:                 CHAR10
No interval rolling:                  Do not select
Number range transaction:             SCDN
Warning %:                            10.0
Main memory buffering:
No. of numbers in buffer:             10
You must define the following interval:
Interval No. 01
from 0000000001
to 9999999999
internal number assignment
Please look st SAP Note: <b>659573</b>
Hope it helps.
Please award points if it is useful.
Thanks & Regards,
Santosh

TPETIME and long running transactions

Tuxedo version and patch: Tuxedo Version 8.1, 32-bit, Patch Level 328
Issue:
One of the services we have is exhibiting very high response times (as gathered from the stderr log using -r option). In some instances the reported response time has reached 827 seconds. Now, my understanding says that since the default timeout in Tuxedo is set to 300 seconds, the service should have timed out and it did not. I checked if there is a SVCTIMEOUT setting for this service in the ubbconfig file, but there is not.
I am confused as in why this service did not timeout as expected? Is there a known issue with Tuxedo 8.1 and is there a patch for it (i searched the forum but didn't find any)?
Any help/hints appreciated.

Hi,
there are many different kinds of timeouts available in Tuxedo and it might feel confusing sometimes.
Timeouts can be viewed from two different perspectives - that of the client (calling the service) and that of the service/server itself.
From the client's point of view, a service call using tpcall() is generally subject to a timeout, defined by BLOCKTIME*SCANUNIT in the ubbconfig, or a service-specific BLOCKTIME in newer versions of Tuxedo (called "blocking timeout", default 60 seconds). If the service call lasts (more than SCANUNIT seconds) longer than the blocking timeout, tpcall() will fail with tperrno TPETIME.
The client can avoid this by setting the flag TPNOTIME, in which case the tpcall() call will "hang" until the service finally returns something. (I would personally recommend against this, but that's another story...)
From the service/servers point of view, a blocking timeout is never really an issue (unless the service performs a nested call, but in that case it becomes a client!). The service will continue its work until it finally reaches the point of tpreturn() (or possibly tpforward()). It has no real understanding that the client might have given up a long time ago (with a TPETIME error), it will do whatever it takes to try to deliver a response, sometimes causing entries in the ULOG if the client has terminated and the delivery is impossible.
If you want to avoid this, you need to define a SVCTIMEOUT in the ubbconfig for the service in question. If you do that, Tuxedo will monitor the server side of the service call and brutally abort the server process (kill it by means of a unix signal) if a service call hosted by that process lasts (more than SCANUNIT seconds) longer than the SVCTIMEOUT specified for that service. If you have defined the server with RESTART=Y (and MAXGEN=n!!!), Tuxedo will then restart the server automatically, which is probably a good thing. I'm not 100% sure what the client will receive, but probably a TPETIME. (If you have specified TPNOTIME you might actually get into trouble in this case.)
In order not to make things too easy, there's also the possibility of a transactional timeout (as opposed to blocking timeout). A transactional timeout is a mechanism to protect databases and other users from transactions/locks with too long durations, and as such is is somewhat more potent than a blocking timeout (that is only protecting a single client from waiting too long).
If a transactional timeout is in effect, it will always override the blocking timeout.
To return to your question, it is my belief that the client in your case experienced a timeout (TPETIME) error after some 300 seconds, if that's your configured BLOCKTIME (60 used to be the default). As the server did not really know this, it continued doing work (in vain) for another 527 seconds before reaching tpreturn(), where it wrote timing information for txrpt and tried to return a response to the client that already had given up all hope.
Does this make any sense to you?
Best regards,
/Per

EWT and Professional User Transaction

Similar Messages

Maybe you are looking for