The input line is too long.The syntax is incorrect.

While trying to run Managed Server from cmd , I was stuck with following error.

The input line is too long.The syntax is incorrect.


Solution is too configure the Command Prompt

Configure the command prompt Open Command Prompt Click the upper-left corner of the Command Prompt window, and then click Properties. Click the Options tab. In Command History, type or select 999 in Buffer Size, and then type or select 5 in Number of Buffers. That will take you to 5000 For more:--Click Here

File naming convention in File Adapter

11.1.1.x docs states that:

Additionally, you can combine file naming conventions. For example, you can specify the file naming convention as po_%SEQ%_%yyyy.MM.dd%_%SEQ%.txt. 

However, when I add this (via copy/paste) into the file name convention space and tab out, I get this error:

Output file naming convention can only have a single dynamic part.


Solution


This can be solved by directly editing the .jca file from backend. This problem occurs when we use wizard for these type of naming conventions.

Copy a very large file (~gigs) from one directory to in BPEL/ESB

Use case I: Move an extremely large file from one directory to another in an opaque manner

 There are cases where the customer just wants to move/copy a file from one directory to another without reading the content of the file into BPEL/ESB. In order to do so, you will need to configure the FileAdapter in the following manner:

     <jca:binding  />
        <operation name="MoveFile">
      <jca:operation
          InteractionSpec="oracle.tip.adapter.file.outbound.FileIoInteractionSpec"
          SourcePhysicalDirectory="foo1"
          SourceFileName="bar1"
          TargetPhysicalDirectory="foo2"
          TargetFileName="bar2"
          Type="MOVE">
      </jca:operation>

Please note that the Source/Target endpoint details can be overridden via the header mechanism.

Use case II: Move an extremely large file from one directory on one FTP Server to a Local file-system and vice-versa

There are cases where the customer just wants to move/copy a file from the ftp server to a local file system folder and vice versa.

The new interaction has the concept of source and/or target being remote or local e.g.

    <binding name="IO_binding" type="tns:SynchRead_ptt">
    <jca:binding  />
        <operation name="IO">
      <jca:operation
         FileType="binary"
          InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
          SourcePhysicalDirectory="foo1"
          SourceFileName="bar1"
          TargetPhysicalDirectory="foo2"
          TargetFileName="bar2"
          Type="MOVE">
     </jca:operation>

        </operation>
    </binding>
    <service ..>
        <port ..>
        <jca:address location="eis/Ftp/FtpAdapter" />
        </port>
    </service>

In this case, both foo1 and foo2 are considered to be folders on a remote ftp server. The location of the server is governed by the JNDI location e.g. eis/Ftp/FtpAdapter.

However, if we want foo1 to be a folder on the remote ftp server and foo2 be a folder on the local system running the adapter then, we need to specify that in the interaction spec e.g.

 <jca:operation
         FileType="binary"
          InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
          SourcePhysicalDirectory="foo1"
          SourceFileName="bar1"
          TargetPhysicalDirectory="foo2"
          TargetFileName="bar2"
          TargetIsRemote="false"
          Type="MOVE">
     </jca:operation>

By specifying a TargetIsRemote as "false", we're saying that the TargetPhysicalDirectory is a local file system. Hence in this case, the MOVE operation will move the file "bar1" a remote file system on ftp server (foo1) to a local file system (foo2).

Similarly,  

 <jca:operation
         FileType="binary"
          InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
          SourcePhysicalDirectory="foo1"
          SourceFileName="bar1"

         SourceIsRemote="false"

          TargetPhysicalDirectory="foo2"
          TargetFileName="bar2"
          Type="MOVE">
     </jca:operation>

By specifying a SourceIsRemote as "false", we're saying that the SourcePhysicalDirectory is a local file system. Hence in this case, the MOVE operation will move the file "bar1" a local file system (foo1) to a remote file system on ftp server(foo2). 

If these parameters are both absent, they default to true e.g. 

 <jca:operation
         FileType="binary"
          InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
          SourcePhysicalDirectory="foo1"
          SourceFileName="bar1"

         SourceIsRemote="true"

          TargetPhysicalDirectory="foo2"
          TargetFileName="bar2"

         TargetIsRemote="true"

          Type="MOVE">
     </jca:operation> 

Use case III: Move an extremely large native file (in csv format) to another directory (in fixed length format) using the new interaction [Basically the FlatStructure sample on a 1 gig file]

 There are cases where the customer wants to do the following:

i) Read a huge native csv file(~1 gig) from a directory

ii) Translate the csv into XML

iii) Run the resulting XML through a transformation

iv) Translate the transformed XML back to a delimited file.

    <jca:binding  />
        <operation name="MoveWithXlate">
      <jca:operation
          InteractionSpec="oracle.tip.adapter.file.outbound.FileIoInteractionSpec"
          SourcePhysicalDirectory="foo1"
          SourceFileName="bar1"
          TargetPhysicalDirectory="C:\JDevOOW\jdev\FileIoOperationApps\MoveHugeFileWithXlate\out"
          TargetFileName="purchase_fixed.txt"
          SourceSchema="address-csv.xsd" 
          SourceSchemaRoot ="Root-Element"
          SourceType="native"
          TargetSchema="address-fixedLength.xsd" 
          TargetSchemaRoot ="Root-Element"
          TargetType="native"
          Xsl="addr1Toaddr2.xsl"
          Type="MOVE">
      </jca:operation>
      <input>
        <jca:header message="hdr:OutboundHeader_msg" part="outboundHeader"/>
      </input>
        </operation>
    </binding>

As you can see that we have the schema details for the source file and target file. These schemas should be imported into the process. The Xsl parameter specifies which XSL file to use.

New OFM versions released SOA Suite 11.1.1.4 & BPM 11.1.1.4 & JDeveloper 11.1.1.4 WebLogic on JRockit 10.3.4

Oracle SOA Suite 11g Installations

This is the latest release of the Oracle SOA Suite 11g. Please see the Documentation tab for Release Notes, Installation Guides and other release specific information. Please also see the List of New Features and Samples provided for this release.

Release 11gR1 (11.1.1.4.0) Microsoft Windows (32-bit JVM) Linux (32-bit JVM) Generic

Oracle JDeveloper 11g Rel 1 (11.1.1.x) (JDeveloper + ADF)

Integrated development environment certified on Windows, Linux, and Macintosh. License is free (read the Pricing FAQ).

Studio Edition for Windows (1.2 GB) | Studio Edition for Linux (1.3 GB) | See All

See Additional Development Tools

Oracle WebLogic Server 11g Rel 1 (10.3.4) Installers

The WebLogic Server installers include Oracle Coherence and Oracle Enterprise Pack for Eclipse and supports development with other Fusion Middleware products . The zip includes WebLogic Server only and is intended for WebLogic Server development only.

Linux x86 (1.1 GB) | Windows x86 (1 GB)

Zip for Windows x86, Linux x86, Mac OS X (316 MB) | See All

Oracle WebLogic Server 11gR1 (10.3.4) on JRockit Virtual Edition Download

For additional downloads please visit the Oracle Fusion Middleware Products Update Center

java.lang.OutOfMemoryError: PermGen space KILLER

When did I see this happen?

I seem to have seen this in 2 different places with in BPEL world so far.

Firstly when I try to use the automated deployment process while deploying to System Test or Use Acceptance Test (UAT) and even in pre-prod some times. I have this whole bunch of about 30+ bpel processes to deploy and have a automated deployment process to do this. In random order in the middle of deployment you get this crap.

Secondly I have even seen this in Development environment, while deploying BPEL process from JDeveloper.

I have never seen this happen any other time at least in the scenarios that I have worked in.

Where do you see this?

If I take this second one first, I mean JDeveloper deployment in DEV, then it is in the JDeveloper logging window.

Now to the first scenario is a bit of a pain. You have a deployment running and all of a sudden the deployment fails. Time to dig into the opmn log file and find these words there.
"java.lang.OutOfMemoryError: PermGen space"

What the hell is PermGen space?

First of all it is NOT PermGem space but it is Perm Gen space.
PermGen stands for Permanent Generation.

How the hell is this related to BPEL?

The answer is both No and Yes.

Why NO?

This weired error is not a BPEL error but a java JVM memory error.

Why YES?

You see this crap come up while deploying BPEL.

So what is the background of PermGen Error?

Well let us dig into java. JVM has this memory called virtual memory. This is the memory that JVM uses to work with what ever it has in hand.
But JVM has 3 different space of it.
The Young, Tenured and Perm.

All the objects that get created are first stored in Young Generation. If the objects survive long enough from garbage collector they get transferred to Tenured Generation.

Now Permanent Generation is special. When there is no space left in Perm you see this error.

So what does Perm Gen contain?

Permanent Generation is special as it contains class definitions.
Objects are in Young and Tenured Generation.

Basically it contains

• Basic fields of java class
• Methods of a class (including the bytecodes)
• Names of the classes
• Constant pool information
• Object arrays and type arrays associated with a class
• Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)
• Information used for optimization by the compilers (JITs)

There are a few more pieces in there but this is most of it.

So what causes Perm Gen?

As you are loading BPEL through some ANT task.
ANT runs the java stuff to load BPEL.

The class loader that loads the BPEL fills up the Permanent Generation with the class details of all the classes that you have loaded.

What is the default PermGen?

The default max permanent generation size is 64M, not quite enough.

What is recommended?

1024 is recommended.

How to control this?

Use the following with the command line
-XX:MaxPermSize=1024m

What does -Xms and -Xmx do to PermGen?

These 2 parameters does nothing to change the Perm Gen space setup by JVM.
You just do want to default Max Perm Gen space to 64 M.

Is this the final solution?

Not really, if you keep loading loads of new processes or huge number of classes this might delay your Out Of Memory Error but will not fix it.

The only solution?

The only solution is to bounce the server once you see this error.

Where else?

This is a general issue faced by all sun java based servers. When huge number if class are loaded as part of an application, this error is expected.

Delimited String to XML nodeset

INPUT

  <?xml version="1.0" encoding="UTF-8" ?>

<ns1:process xmlns:ns1="http://xmlns.oracle.com/Application2_jws/delimitedstring/BPELProcess1" xmlns:wsa="http://www.w3.org/2005/08/addressing">

  <ns1:input>a,b,c,d,e</ns1:input>

  </ns1:process>

EXPECTED OUTPUT


<outputVariable>
<part name="payload" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><processResponse xmlns="http://xmlns.oracle.com/Application2_jws/delimitedstring/BPELProcess1">
   <result>a</result>
<result>b</result>
<result>c</result>
<result>d</result>
<result>e</result>
</processResponse>
</part>
</outputVariable>

LOGIC

<assign name="Assign_1">
            <bpelx:copyList>
                <bpelx:from expression="oraext:create-nodeset-from-delimited-string('{http://xmlns.oracle.com/Application2_jws/delimitedstring/BPELProcess1}result',bpws:getVariableData('inputVariable','payload','/client:process/client:input'),',')"/>
                <bpelx:to variable="outputVariable" part="payload"
                          query="/client:processResponse/client:result"/>
            </bpelx:copyList>
        </assign>

Few points to note about Oracle DB Adapter

• The operation Update Only sometimes performs inserts/deletes for child records. That is, an update to Master could involve a new or deleted detail. So if the input to update contains only one detail record, then the other detail records in the table are deleted.

• Schema Bound XML tables are not supported.

• Oracle Database Adapter only supports tables where there is a primary key defined. If primary key constraints have not been defined on a table explicitly, then you must provide one at design time while defining the Oracle Database Adapter by using the Adapter Configuration Wizard. If you do not provide a valid primary key, then the unique constraint is not guaranteed, and this could result in possible loss of messages at run time. That is, rows with duplicate primary key values are likely to be lost.

• Oracle recommends that you use varchar instead of char for primary key columns, otherwise you will need to set the weblogic-ra.xml property shouldTrimStrings to false. The truncation of trailing spaces could cause the primary key to be read incorrectly, making it impossible to update read rows as processed.

• Incase of polling with Sequencing Table/Update an External Sequencing Table, ensure that the name of the table in the SELECT query matches the case of the data in the sequencing table.

• The WHERE clause applies to SELECT operations only (that is, polling for new or changed records or performing a SELECT operation on a table). It does not apply to INSERT, UPDATE, and DELETEoperations.

• You must use a non-XA driver with the SOALocalTxDataSource parameter. Switching to an XA driver breaks product functionality.

• For Oracle Database Adapter with polling operation in a clustered environment, you must use the option of distributed polling by selecting the Distributed Polling check box in the Adapter Configuration Wizard.

• The name of stored procedures or packages that refers to database or user-defined data types must not include the character $ in it. The presence of $ in the name would cause the XSD file generation to fail.