TestStand Deployment Issues

Right now we are in the process of building deployment packages for our test stations in TestStand.  We basically have some model customizations as well as the actual client sequence file, which calls VI's.  These VI's do have sub-VI's which are distributed with the package.  I can get the whole package to deploy (both install and image files), but when I try to run the deployed package on the target computer using a customized user interface, I recieve error -18001.  The error dialog box informs me that the VI cannot be run, because the NI LabView Development System cannot be found.  In my client sequence file I went through all the VI's and made sure they always run in runtime mode.  I also set the LabView adapter on my development computer to runtime v8.5 for when I deploy.  I'm quite baffled at this point as to why I'm still having issues.  Could it be an issue with my user interface instead, or how do I remedy this issue?
Message Edited by schm1347 on 10-26-2007 10:42 AM

Hi, schm1347,
The adapter info is stored in <TestStand>\cfg\TestExec.ini file. So when you make your deployment, you should include this file and deploy it to the same folder on the target computer, as shown in the attached screenshot.
In general, if you want to keep the TestStand settings on the target machine the same as the development computer, you should include the cfg folder. It includes user management, station global, execution options, etc.
Regards,
Song D
Message Edited by Song D on 10-29-2007 11:36 AM
Regards,
Song Du
Systems Software
National Instruments R&D
Attachments:
ss.JPG ‏72 KB

Similar Messages

  • TestStand Deployment Issue - VI too early to convert

    I have a test system which has LabVIEW 8.0 and TestStand 3.5 running VIs and sequences developed on this system. I am trying to replace this with a deployment system and not having much success. I admit I'm pretty green with LV8 and TS3.5, but reasonably computer savvy.
    I purchased the same DAQ boards used in the existing system and installed them in a new PC. The PCs are different types, the existing system is a HP Pavilion and the deployment system is a Dell. I didn't think hat would have much effect.
    I created a deployment install image on the development system. I tried this a few months ago and was able to get a simple test deployment working. Now that I've got the actual DAQ hardware, I attempted to deploy the full test system. It installed OK on the deployment system, but when I run a sequence, I get a message that states:
    LABVIEW: VI version is too early to convert to the current LABVIEW version.
    The notable differences between the two systems include:
    1. Different PC types
    2. Possibly a different DAQmx version - I installed DAQmx from the CDs that came with the new hardware, not from the original CDs.
    3. XP Pro instead of XP Std
    Any suggestions? Like I said, I don't have a lot of experience with this, so any help is appreciated.
    Thanks,
    Blair

    Thanks, Rick. I tried checking Daqmx 8.0 as one of the drivers to load with the build and got an error. The error indicated that the driver couldn't be loaded as Measurement Studio wasn't installed.
    I'll have to see if I can find the original drivers that were used with the old system and remove the drivers from the new system and install the old drivers. I suppose I could try installing the new drivers on the old system and then doing the build, but I hesitate to do that as I am afraid that something will get broken on the old system and shut down production. I've already had one issue during start-up that caused the license to invalidate and had to re-install the license, so I would rather not make any changes at this time.
    Unfortunately, a subcontractor created the original system, and I don't know if I have the original driver disks.
    The driver disks that came with the new DAQ boards show ver 8.6.
    The version number of Measurement and Automation Explorer is the same.
    Blair

  • TestStand Deployment problems with visarc issues

    Recently I attempted to rebuild a TestStand Deployment that I had build just 1 month before and it wouldn't create the deployment.  Changes that occurred between the last build and this build was an upgrade to LV 8.6.1 from LV 8.6.
    The issue was that the file visarc was not able to be found by the deployment engine and wouldn't progress much beyond the tsw file verification.  It turned out that having multiple versions of LV on my harddrive screwed up the linking on this file and caused the deployment to fail.
    The following link solved the issue and allow the deployment to be built:
    http://digital.ni.com/public.nsf/allkb/833BFD5E9CA​0224886257584004DAA4C
    I don't really have a question, just wanted to get this out there so fewer people have to sustain the pain that I went through.

    Thanks for the input
    Regards
    Ray Farmer
    Regards
    Ray Farmer

  • Assessing Command 'Analyze Source Files' via Command Line when running TestSTand Deployment Utility

    Our Software Configuration Manager is running the TestStand Command Line Deployment Build Tool (Ref: https://decibel.ni.com/content/docs/DOC-38947).
            When he builds the application,  the code will not be at the same location it was in development. 
    If you are Manually running the TestStand Deployment Utility, This is not a problem because everything is relative in the workspace.   Simply go to the Distributed Files Tab (of TestSTand Deployment Utility) and hit the, "Analyze Source Files" button.  This finds the required files and apparently creates an updated hard path to be used during the build (probably in the *.tsd).
    PROBLEM:  We auto-run the Command Line Deployment Build Tool (Command Line), and we do not have access to the, 'Analyze Source Files' command.
                As a result, our build consist of many warnings and the output is missing many files (the location of the files have not been updated).
    If we could access the 'Analyze Source Files' Command via command line, that would fix the issue. 
    FYI:  We use an automatic builder called Quick Build as our builder.
    Attachments:
    TestSTand Deployment Utility-Distributed Files Tab.PNG ‏76 KB

    Unfortunately it looks like Analyze Source Files does not have a command equivalent for the command line based on this article and attached PDF:
    https://decibel.ni.com/content/docs/DOC-38947
    That may be a good post for the TestStand Idea Exchange for consideration in future versions of TestStand.
    Michael K.

  • TestStand Deployment Not Installing Files

    TestStand 3.1
    We have created a custom OI and Process Model and we have attempted to
    create an installer using the TestStand Deployment Utility.  The
    problem is that when the installer is first run on the target system,
    some files are not being installed.  We had a similar problem with
    the Distribution Kit functiontionality of CVI 6, and were never able to
    fully resolve the issue.
    Basically the installer examines files that already exist on the target
    machine and will not overwrite them if they have been modified. 
    The installer is smart enough to examine version numbers inherent to
    DLLs and EXE files (and adding REINSTALLMODE=amus to setup.ini causes
    these types of files to always be overwritten).  However, for
    other files such as *.ini and *.seq files, there seems to be no way to
    force the installer to overwrite these files.
    The workaround that we used previously was to run the installer 3 times
    (once to install, once to uninstall which deletes all files including
    the old versions that were not overwritten, and then once to actually
    install the desired files).  Is there a way around this with the
    TestStand Deployment Utility?  We are actually considering
    bypassing the installer altogether and just copying the files in the
    image directory that the Deployment Utility creates.
    Thanks,
    Peter

    Hi Peter,
    Thanks for the information. I am not sure if the installer will recognize the sequence file version number. Are you deploying a Process Model from the NI folder, or have you copied it into the User folder? Are you adding the Process Model and INI files to a project in your workspace and deploying the workspace or are you deploying them by selecting to Deploy Files in TestStand User Directories on the System Source tab of the Deployment Utility?
    In other words, what file specifically are not being installed correctly? What is their path on the development machine and what is the target path?
    One last question, if the target is a new system and has not had a TestStand test system deployed to it, how does it have sequence and TestStand INI files on it already? Are you installing TestStand on the target machine before deploying a test system?
    Regards,
    Eric M

  • LabVIEW VI causes TestStand Deployment to fail

    Hello,
    I have a problem with the attached VI.  Any time I include it in a deployment, I get an Error that says "Internal Error Code 1 processing VIs... Installer not created due to an Error"
    The VI and a simple sequence file are attached.
    Attachments:
    IsMyProcessRunning.vi ‏13 KB
    ProcessTest.seq ‏5 KB

    Simon,
    The following (below) is the Deployment improvements for TestStand 4.2.  I haven't been able to look at the VI of the original post so I dont know of the actual problem but there are still issues with the deployment tool in TS4.2
    Regards
    Ray Farmer
    TestStand Deployment Utility Improvements
    The TestStand Deployment Utility now uses improved internal caching to accelerate analysis and build times. Additionally, the LabVIEW VI Options dialog box includes the following new options so you can choose between faster performance and improved error handling:
    Check for Broken VIs During Analysis—When enabled, the TestStand Deployment Utility checks for broken VIs during analysis. This option is disabled by default to improve performance. Enable this option when you want to debug VI errors.
    Check for Broken VIs After Build—When enabled, the TestStand Deployment Utility checks for broken VIs in the image directory when building an image. This option is enabled by default to ensure that distributed files do not contain broken VIs. Disable this option for better performance if you are rebuilding and have not made changes to VIs.
    Remove Unused SubVIs—Removes unused polymorphic subVIs and disconnects type definitions when building. This option is disabled by default for backward compatibility. Enable this option for better performance and to deliver a smaller number of subVIs.
    Note  Enabling the Remove Unused SubVIs option disables certain editing and debugging options on the deployed system, such as wiring a new type to a polymorphic VI or making type changes across several VIs by editing a type definition.
    The Deployment Utility also better integrates with LabVIEW 8.6.1 or later for improved build speeds and deployment of advanced LabVIEW features, such as VIs that include LabVIEW object-oriented programming.
    The Installer Properties section of the Distributed Files tab of the TestStand Deployment Utility also includes a new Force File to Install option. Enable this option to force the installers the deployment utility builds to always overwrite existing files.
    Refer to Chapter 14, Deploying TestStand Systems, of the NI TestStand Reference Manual and to TestStand Deployment Utility for more information about the TestStand Deployment Utility.
    Regards
    Ray Farmer

  • TestStand Deployment Error Code 1055 when using LabVIEW Storage VIs

    After a couple of days of playing with the TestStand Deployment. I final tracked down the VI that was causing this Error.
    It was using thethe LabVIEW Storage VIs to save data to a TDM file.
    My work around at the moment is to use a Wrapper VI and call this VI by reference.
    That way the TestStand Deployment can't detect the Storage VIs.
    I'm using LabVIEW 8.6.1 and TestStand 4.1.1 does anyone know if this issue has been address in TestStand 4.2?
    Looks like the upgrade might be worth it.
    Simon Holman
    Software Engineer
    Certified LabVIEW Developer
    Certified TestStand Developer
    measX GmbH & Co. KG.
    http://www.measx.com
    Solved!
    Go to Solution.

    Hi Simon,
    I tested your sequence file in TestStand 4.2 and I didn't get any error! Which version of TestStand do you have? Can you post a screenshot of the complete internal error pop up?
    Usually internal errors can be eliminated with the Clean Reinstall Procedure.doc, where you will remove all NI software and all references to NI software from your computer to start over with a fresh installation!
    I hope these informations help you!
    Best regards
    Suse
    Certified LabVIEW Developer (CLD)
    Attachments:
    Clean Reinstall Procedure.doc ‏32 KB

  • TestStand Deployment Utility Error

    I am getting the error below when attempting to build a TestStand deployment.  I am running TestStand 4.2.1.83 and LabVIEW 2009 Service Pack 1 Version 9.0.1f3.  Any help would be appreciated as I cannot find any of the VIs mentioned in the error.  Thanks!
    Starting Log.
    Starting Analysis
    Processing Workspace...
    Workspace Processed
    Finished Analysis
    Building...
    10:15 AM
    Internal error code 6503 Processing VIs...
    Could not process LabVIEW VIs. Fix any broken VIs before rebuilding. LabVIEW error:
    Exception occured in LabVIEW: LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select <b>File>>Open</b> to open the VI and then verify that you are able to run it. in Dynamically Call Build VI Distribution LV 8.6 or Above - TestStand.vi->TestStand - Call Build VI Distribution for Unique VI Hierarchies LV 8.6 or Above.vi->TestStand - Package VIs.vi->TestStand - Build.vi->TestStand - Distribution Wizard GUI.vi->TestStand - Deployment Utility Splash Screen.vi
    An installer was not created due to an error
    The build process is done.
    10:15 AM
    Aborted
    Solved!
    Go to Solution.

    Hello George Mah,
    I found CARs # 258761 and # 3OP9RE6I for TestStand which may be related to this issue and to error 6503.  The error was created because VIs with duplicate names were included in a deployment.  Would you verify that you do not have any duplicate VIs in your project?  Are you noticing anything else strange with your deployments?  Have you tried creating a blank deployment that only includes the TestStand engine or a run-time engine?  
    Regards,
    Shawn S. | NIC
    Instrument Driver/IVI PSE
    National Instruments

  • Unable to include Operator Interface in TestStand deployment

    Hello.  I have created a test system using TestStand 3.5. 
    There is only one sequence file, and this sequence calls several VIs
    that I have created in LabVIEW 8.0.  I would like to distribute
    this test system to a target computer, which will then run the default
    Operator Interface.  No bells and whistles, just plain and
    simple.  However, I'm running into problems.
    First, I created a Workspace file in TestStand.  I then added a
    Project to it.  In the Project, I added all necessary files for my
    project (the sequence file as well as all of the custom VIs). 
    Then I proceeded to follow the TestStand reference manual in order to
    deploy my system.
    For reference, text in italics is the reference guide and text in bold is my comments.
    Deploying the TestStand Engine
    1. Launch the TestStand Deployment Utility by selecting Tools»Deploy
    TestStand System from within the sequence editor.
    I did this, and set up my build how I wanted it.
    2. On the System Source tab, enable the Deploy Files in TestStand User
    Directories option.
    This option collects files from the <TestStand>\...\User
    directories, so that any customizations that you have made to process
    models, step types, language strings, and so on, will be distributed to
    the target computer.
    I did this, and copied my Operator Interfaces\NI folder to Operator
    Interfaces\User.  This would assure (I hope) that I would have the
    default operator interfaces included in my project.
    3. On the Installer Options tab, enable the Install TestStand Engine
    option.
    Done.
    4. On the Installer Options tab, click Engine Options to launch the
    TestStand Engine Options dialog box, which you use to select the
    TestStand components that should be present in the installer.
    Done.  Everything is checked.
    In the TestStand Engine Options dialog box, expand Operator
    Interfaces»Full-Featured in the tree view.
    a. Click the X next to LabWindows/CVI to include the
    Full-Featured LabWindows/CVI Operator Interface in the engine
    installation. The X should become a green checkmark.
    b. Click OK to accept the new settings and close the dialog box.
    This is where things go wrong.  There is NO Operator Interfaces box in my tree view.  It simply doesn't exist.
    I've tried several different builds using different strategies. 
    I've done builds with the CVI operator interface in the User directory,
    and I've also tried copying over the files manually.  On the
    target computer, I've always gotten either an error message (Could not
    open the TestStand Engine), or else TestStand opens in evaluation
    mode.  In both cases, my custom VIs and sequence files are nowhere
    to be seen.  Can anyone shed some light on this?  It's
    driving me a bit crazy!
    Thanks very much,
    Brett Gildersleeve

    Hi Brett,
    Whenever you deploy your TestStand application to target machines, you will always needs a license.  The licenses for distributing TestStand are different than for distributing LabVIEW and LabWindows/CVI code modules.
    LabVIEW does not require you to purchase any run-time licenses for a deployment system. You can even run LabVIEW VIs in VI format (not executables) from TestStand without using the development environment and without an additional license.
    In order to run LabWindows/CVI code modules, you will need the LabWindows/CVI Run-Time engine which is also available free of charge.
    Regarding TestStand, you will need a license for each machine that runs a TestStand sequence. TestStand has three types of licenses which are the TestStand Development System License, the TestStand Debug Deployment Environment License, and the TestStand Base Deployment Engine License.
    TestStand Development System License
    The TestStand Development System License is required for any test sequence development and/or editing of existing TestStand sequence files that you perform within the TestStand Sequence Editor or programmatically using the TestStand API.
    TestStand Debug Deployment Environment License
    The TestStand Debug Deployment Environment License gives you maximum flexibility for deploying TestStand and LabVIEW, LabWindows/CVI, and Measurement Studio-based systems. This license allows you to install the development versions of TestStand, LabVIEW, LabWindows/CVI, and Measurement Studio, along with any corresponding add-on toolkits, so that you can debug your test application on your deployed test station. This license does not include the ability to perform any development tasks within the TestStand Sequence Editor or programmatically using the TestStand API.
    The TestStand Debug Deployment Environment License has debugging capabilities including settings breakpoints, monitoring variable values, and stepping into test code directly from the TestStand sequence.
    (Note: This license does not provide the software but rather gives you the right to install a previously purchased piece of software on the target machine.)
    TestStand Base Deployment Engine License
    The TestStand Base Deployment Engine License is the minimum license required for all deployed TestStand-based applications. This license allows you to deploy the TestStand Engine, a TestStand Operator Interface, and TestStand sequence files to the single test station for which the license is applicable.
    The TestStand Base Deployment Engine License provides simple sequence debugging capabilities, including setting breakpoints and single stepping through test sequences in your Operator Interface. You cannot save sequences and open the sequence editor.
    I hope this clears things up.
    Best Regards,
    Jonathan N.
    National Instruments

  • Outbound BPEL Process deployment Issue in SOA (binding.jca-12600)

    Hi,
    I have Designed an Outbound BPEL Process for Siebel CRM Service Integration using Jdeveloper (11.1.1.3.0). After that I am facing the deployment issue of this application in SOA suite (11.1.1.6.0). Following is the deployment.log status in jdeveloper:-
    [10:57:54 AM] ---- Deployment started. ----
    [10:57:54 AM] Target platform is (Weblogic 10.3).
    [10:57:54 AM] Running dependency analysis...
    [10:57:54 AM] Building...
    [10:57:58 AM] Deploying profile...
    [10:57:58 AM] Wrote Archive Module to C:\JDeveloper\mywork\Siebel_Outbound_BPEL\QueryWithView_Invoke\deploy\sca_QueryWithView_Invoke_rev1.0.jar
    [10:57:58 AM] Deploying sca_QueryWithView_Invoke_rev1.0.jar to partition "default" on server AdminServer [10.10.22.81:7001]
    [10:57:58 AM] Processing sar=/C:/JDeveloper/mywork/Siebel_Outbound_BPEL/QueryWithView_Invoke/deploy/sca_QueryWithView_Invoke_rev1.0.jar
    [10:57:58 AM] Adding sar file - C:\JDeveloper\mywork\Siebel_Outbound_BPEL\QueryWithView_Invoke\deploy\sca_QueryWithView_Invoke_rev1.0.jar
    [10:57:58 AM] Preparing to send HTTP request for deployment
    [10:57:59 AM] Creating HTTP connection to host:10.10.22.81, port:7001
    [10:57:59 AM] Sending internal deployment descriptor
    [10:57:59 AM] Sending archive - sca_QueryWithView_Invoke_rev1.0.jar
    [10:58:00 AM] Received HTTP response from the server, response code=500
    [10:58:00 AM] Error deploying archive sca_QueryWithView_Invoke_rev1.0.jar to partition "default" on server AdminServer [10.10.22.81:7001]
    [10:58:00 AM] HTTP error code returned [500]
    [10:58:00 AM] Error message from server:
    #;There was an error deploying the composite on AdminServer: Deployment Failed: [JCABinding] [QueryWithView_Invoke.QueryWithView/1.0]Unable to complete load due to: Generic error.
    #;Generic error.
    #;Cause: Unable to find suitable outbound binding.
    #;Please create a Service Request with Oracle Support.
    #;: Generic error.
    #;Generic error.
    #;Cause: Unable to find suitable outbound binding.
    #;Please create a Service Request with Oracle Support.
    [10:58:00 AM] Check server log for more details.
    [10:58:00 AM] Error deploying archive sca_QueryWithView_Invoke_rev1.0.jar to partition "default" on server AdminServer [10.10.22.81:7001]
    [10:58:00 AM] #### Deployment incomplete. ####
    [10:58:00 AM] Error deploying archive file:/C:/JDeveloper/mywork/Siebel_Outbound_BPEL/QueryWithView_Invoke/deploy/sca_QueryWithView_Invoke_rev1.0.jar
    (oracle.tip.tools.ide.fabric.deploy.common.SOARemoteDeployer)
    And the following is the SOA Server Side log file status:-
    ####<Jun 3, 2013 10:36:05 AM AST> <Info> <Health> <HOSADDAT02> <AdminServer> <weblogic.GCMonitor> <<anonymous>> <> <4be72ac3bdb5ebae:-a61256d:13f08d94c98:-8000-00000000000000f4> <1370244965280> <BEA-310002> <36% of the total memory in the server is free>
    ####<Jun 3, 2013 10:36:12 AM AST> <Error> <ServletContext-/soa-infra> <HOSADDAT02> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <weblogic> <> <4be72ac3bdb5ebae:-a61256d:13f08d94c98:-8000-000000000000182b> <1370244972343> <BEA-000000> <Error during deployment
    oracle.fabric.common.FabricException: Deployment Failed: [JCABinding] [QueryWithView_Invoke.QueryWithView/1.0]Unable to complete load due to: Generic error.
    Generic error.
    Cause: Unable to find suitable outbound binding.
    Please create a Service Request with Oracle Support.
    : Generic error.
    Generic error.
    Cause: Unable to find suitable outbound binding.
    Please create a Service Request with Oracle Support.
         at oracle.integration.platform.blocks.deploy.StandaloneCompositeDeploymentCoordinatorImpl.coordinateCompositeDeployment(StandaloneCompositeDeploymentCoordinatorImpl.java:64)
         at oracle.integration.platform.blocks.deploy.servlet.BaseDeployProcessor.deployNewComposite(BaseDeployProcessor.java:415)
         at oracle.integration.platform.blocks.deploy.servlet.BaseDeployProcessor.deploySARs(BaseDeployProcessor.java:250)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeployWork(DeployProcessor.java:167)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeployWork(DeployProcessor.java:112)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeploy(DeployProcessor.java:99)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.process(DeployProcessor.java:81)
         at oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerServlet.doPostInsideLoggingSession(CompositeDeployerServlet.java:219)
         at oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerServlet.doPost(CompositeDeployerServlet.java:130)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273)
         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)
         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
    Caused By: oracle.fabric.common.FabricDeploymentException: [JCABinding] [QueryWithView_Invoke.QueryWithView/1.0]Unable to complete load due to: Generic error.
    Generic error.
    Cause: Unable to find suitable outbound binding.
    Please create a Service Request with Oracle Support.
    : Generic error.
    Generic error.
    Cause: Unable to find suitable outbound binding.
    Please create a Service Request with Oracle Support.
    {rootCauses=[]}
         at oracle.integration.platform.blocks.adapter.AdapterReference.load(AdapterReference.java:458)
         at oracle.integration.platform.blocks.adapter.AdapterReference.load(AdapterReference.java:82)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentConnection.deployReferences(CompositeDeploymentConnection.java:201)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentConnection.deploy(CompositeDeploymentConnection.java:93)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentManagerImpl.initDeployment(CompositeDeploymentManagerImpl.java:150)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentManagerImpl.load(CompositeDeploymentManagerImpl.java:63)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
         at oracle.integration.platform.blocks.deploy.DeploymentEventPublisher.invoke(DeploymentEventPublisher.java:77)
         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
         at $Proxy314.load(Unknown Source)
         at oracle.integration.platform.blocks.deploy.StandaloneCompositeDeploymentCoordinatorImpl.coordinateCompositeDeployment(StandaloneCompositeDeploymentCoordinatorImpl.java:59)
         at oracle.integration.platform.blocks.deploy.servlet.BaseDeployProcessor.deployNewComposite(BaseDeployProcessor.java:415)
         at oracle.integration.platform.blocks.deploy.servlet.BaseDeployProcessor.deploySARs(BaseDeployProcessor.java:250)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeployWork(DeployProcessor.java:167)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeployWork(DeployProcessor.java:112)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeploy(DeployProcessor.java:99)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.process(DeployProcessor.java:81)
         at oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerServlet.doPostInsideLoggingSession(CompositeDeployerServlet.java:219)
         at oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerServlet.doPost(CompositeDeployerServlet.java:130)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273)
         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)
         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
    Caused By: BINDING.JCA-12600
    Generic error.
    Generic error.
    Cause: Unable to find suitable outbound binding.
    Please create a Service Request with Oracle Support.
         at oracle.integration.platform.blocks.adapter.fw.metadata.AdapterBindingConfig.addAdapterReference(AdapterBindingConfig.java:206)
         at oracle.integration.platform.blocks.adapter.AdapterReference.setupAdapterReference(AdapterReference.java:506)
         at oracle.integration.platform.blocks.adapter.AdapterReference.load(AdapterReference.java:425)
         at oracle.integration.platform.blocks.adapter.AdapterReference.load(AdapterReference.java:82)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentConnection.deployReferences(CompositeDeploymentConnection.java:201)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentConnection.deploy(CompositeDeploymentConnection.java:93)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentManagerImpl.initDeployment(CompositeDeploymentManagerImpl.java:150)
         at oracle.integration.platform.blocks.deploy.CompositeDeploymentManagerImpl.load(CompositeDeploymentManagerImpl.java:63)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
         at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
         at oracle.integration.platform.blocks.deploy.DeploymentEventPublisher.invoke(DeploymentEventPublisher.java:77)
         at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
         at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
         at $Proxy314.load(Unknown Source)
         at oracle.integration.platform.blocks.deploy.StandaloneCompositeDeploymentCoordinatorImpl.coordinateCompositeDeployment(StandaloneCompositeDeploymentCoordinatorImpl.java:59)
         at oracle.integration.platform.blocks.deploy.servlet.BaseDeployProcessor.deployNewComposite(BaseDeployProcessor.java:415)
         at oracle.integration.platform.blocks.deploy.servlet.BaseDeployProcessor.deploySARs(BaseDeployProcessor.java:250)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeployWork(DeployProcessor.java:167)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeployWork(DeployProcessor.java:112)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.doDeploy(DeployProcessor.java:99)
         at oracle.integration.platform.blocks.deploy.servlet.DeployProcessor.process(DeployProcessor.java:81)
         at oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerServlet.doPostInsideLoggingSession(CompositeDeployerServlet.java:219)
         at oracle.integration.platform.blocks.deploy.servlet.CompositeDeployerServlet.doPost(CompositeDeployerServlet.java:130)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
         at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
         at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
         at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)
         at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:119)
         at java.security.AccessController.doPrivileged(Native Method)
         at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:315)
         at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:442)
         at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:103)
         at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:171)
         at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:139)
         at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730)
         at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
         at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273)
         at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)
         at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
    Kindly help me in this regard

    Solution:
    Workaround the issue immediately by removing the "ns1:" qualification on the operation for the binding.jca entry in the composite.xml and redeploying.
    For example:
    From:
    <binding.jca config="BAPI_COMPANYCODE_GETDETAIL_invoke_3P.jca"
    operation="ns1:BAPI_COMPANYCODE_GETDETAIL"/>
    To:
    <binding.jca config="BAPI_COMPANYCODE_GETDETAIL_invoke_3P.jca"
    operation="BAPI_COMPANYCODE_GETDETAIL"/>
    Regards,
    Shaheer Badar

  • Adobe Acrobat 9 Pro deployment issue

    Hello. I am having a deployment issue with Adobe Acrobat 9 using Altiris. I create the rip which is bassically an image of the install. My facility has pruchased 50 seats for this software so I know we are covered for the users that we have to use this software. The issue that I am having after I make the rip, and deploy it to a machine it asks for the CD key again in order to use. Am I having an issue with my installation or is Adobe put some kind of security into their software so that when you try to make a rip of the installation is asks for teh CD Key again after the install? Is this an issue that can be resolved?

    SOLUTION:
    The issue was somehow related to DPI (START > Settings > Control Pannel > Display > Settings Tab > Advanced button). Eventhough the DPI was set to normal, I switched it to LARGE, restarted the machine, logged in after the reboot, changed it back to normal size, restarted again, logged in once more, checked the Printer Preferences and PRESTO --- a properly displayed window.

  • Deploy issue from JDeveloper 10.1.3.5 to OAS 10.1.2

    I have written an application using ADF on JDeveloper 10.1.3.5 and need to deploy it to our OAS 10.1.2. I have run the adfinstaller on the linux server to upgrade the ADF libraries to the correct versions, updated the web.xml files to have the correct versions, changed to J2SE 1.4.2_19 for the application and have still got deployment issues.
    Error
    An error occurred while redeploying application "FormsSiebelIntegration". See base exception for details.
    Resolution:
    See base exception for details.
    Base Exception:
    java.lang.UnsupportedClassVersionError
    com/sun/faces/application/ApplicationAssociate (Unsupported major.minor version 49.0). com/sun/faces/application/ApplicationAssociate (Unsupported major.minor version 49.0)
    Removing the jsf-impl.jar file allows the application to deploy, but when running on the app server I get the following errors:
    OracleJSP: oracle.jsp.parse.JspParseException:
    /codename.jspx: Line # 6, <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:af="http://xmlns.oracle.com/adf/faces" xmlns:afh="http://xmlns.oracle.com/adf/faces/html">
    Help! I'm starting to have total mind block as to what to do next.
    Error: Unable to load taghandler class: http://java.sun.com/jsf/html

    I had already applied all of this before trying to deploy.
    The error seems to be a versioning error in the jsf-impl.jar file as the ApplicationAssociate class is found there. I have changed the JDK and J2EE to 1.4.2 and 1.3 respectively, rebuilt everything, updated all the settings to the right versions for 10.1.2 but it still keeps failing on the deploy.

  • A very urgent deployment issue about DBAdapter

    Hello All,
    I have a very urgent deployment issue about DBAdapter.
    That DBAdapter is connect to DB2 AS400 Database. I have a developing database (jdbc:as400://server01/TEST) and a production database (jdbc:as400://server01/PROD).
    During developing, I used DBAdapter wizard to create it, and import some tables, and set the Adapter to use jabc/DB2DS as connection information for easily deployment later.
    Then I deploy to Production. I configured Data-source.xml and oc4j-ra.xml rightly; I set DB connection point to production database. But the DBAdapter still write into developing Database.
    I checked the DBAdapter, the imported tables are something like this, TEST.table1, TEST.table2. And there are a lot "TEST" located in DB2Writer_toplink_mapping.xml, DB2Writer.xml, TEST.schema, DB2Writer.table1.ClassDescriptor.xml.
    This TEST is refrer to the TEST in connect String jdbc:as400://server01/TEST.
    I think this might be the reason cause the problem. As to production database, "TEST" should replaced by "PROD". If I changed it manually, I have to change every time when switch between TEST and PROD. And I also don't know if it is safe to do it? (I tried, and bring some toplink mapping problem)
    By the way, for Oracle Database, because we use 2 instances for testing and production with same schema name, and do not have this issue.
    Anyone could help and many thanks.
    Kerr
    Message was edited by:
    Kerr

    Hi Kerr,
    The idea is to set up all connections in the BPEL or ESB services with logical names, e.g. typically of the form eis/DB/MyFinancialSystem or eis/DB/MyLogisticsSystem. This way, you do not have to modify code when deploying it onto different environments that serve different purposes.
    When moving your services through their lifecyle, on every environment you deploy these to you will have the same logical connections configured on each instance, e.g. for DEV, QA, SIT, UAT and PROD. Only, in case of QA the actual physical connection is configured to point to the QA instance of the systems that your services interact with whereas in case of UAT it points to the UAT instance of the same system.
    Maybe your problem is caused by connecting as user "SomeUser" when running the DB Adapter wizard during development and actually selecting objects from a different schema than you used to connect with, e.g. "Test" in your case.
    Hth,
    Sjoerd

  • TestStand Deployment Engine Serial Number

    Is there a way to get the Serial Number/License of a TestStand Deployment Engine that is installed on a PC?
    The NI License Manager does not report the Serial Number of the Deployment Engine.
    I have even tried to search the Window Registry.
    We have over 100 TestStand Deployment Licenses in our installed software database. Split between BASE and DEBUG Deployment.
    But I can’t find any way to tell/verify which license is on which machine. Just about all are on XP machine that are in need of replacement.
    Just about all are TestStand 4.1
    Omar

    First of all I'm sorry that NI convinced you that a Debug deployment license was a viable option...   I actually didn't know people would purchase those.  That's funny.
    So the license files are stored in %ALLUSERSPROFILE%\National Instruments\License Manager\Licenses.  I was hoping the serial number would be in there.  But it's not.
    One thing you might want to consider to manage this a whole lot easier is to talk NI into giving you a VLM that you can put on a server and adding all your deployment licenses to it.  We do this and it has saved us thousands, if not 10s of thousands of dollars.  Now we can manage all the deployment licenses on the VLM.  It has also forced us to follow the NI license agreement a lot closer than we were.
    Sometimes you can't have all the computers on the LAN.  In this case you can just assign disconnected licenses but still have VLM manage it for you.
    Your last option would be to set up your own spreadsheet and manage it in there.
    We were in the same boat as you a few years ago.  So we contacted NI and got a list of all the licenses we had purchased in the last 10 years and threw them up on VLM.  Then we had IT go through and look for a specific license file with an activated code inside of it on all the machines on the LAN.  We got that list and contacted each of the PC "owners" and had them switch to point to VLM.  In most cases we found the licenses weren't needed anymore so we could transfer those.
    Hope this helps,
    jigg
    CTA, CLA
    teststandhelp.com
    ~Will work for kudos and/or BBQ~

  • Problem with deploying FPGA host VIs using TestStand deployment utility

    I am using a PCI-7831R FPGA to control an automated test fixture.  I have several host VI's that I am calling from TestStand (4.2.1) in order to control the 7831R.  The host VI's that TestStand calls are setup as sub-VI's and are used for various things such as opening an FPGA reference (which is bound to a strict type def), downloading and executing the files on the 7831R, reading writing to controls, and finally closing the reference.  In the sequence file, I am passing the reference values as a file global so that the host sub-VI's can communicate correctly.  I have all functionality working correctly in TestStand on my development PC.  When I go to deploy this to a production PC, I get errors when the sequence file trys to load the first host VI.  The error basically states that the VI is broken - try to open and run it (which I can't because I have no development license on the production PC).  I am currently trying to deploy this to another development PC to see if I can track down where the VI might be breaking. 
    I have included the lvbitx and strict type def control that the host subVI's reference in my deployment files.  I can't think of anything that I might be missing.  Is there any good documentation on exactly which files I need to include in the deployment when using FPGA Host VIs (the TestStand reference manual is pretty vague at best)?  It seems that any documentation that I read says the TestStand deployment utility will analyze all VI dependencies (other than shared variables).  On a side question, is the strict type def considered a shared variable?
    Has anyone successfully deployed a sequence that calls host VI's?  Any help would be greatly appreciated.  If any of the above needs further clarification please ask away and I will be happy to give more details. 
    Thanks,
    Mike

    Hi hawkstringer
    Do you encounter this problem using a deployed version of your code? Note that the subject of this topic is about deploying an FPGA application.
    I forgot I posted here, in the mean time I've managed to deploy my application. I think my problem was solved when I included all necessary drivers and components (but I'm not absolutely sure). I included the following:
    NI IVI Compliance Package
    NI FlexRIO
    NI PXI Platform Services Configuration Support
    NI R Series Multifunction RIO
    NI DAQmx Core Runtime
    NI DAQmx MAX Configuration Support
    NI RIO
    Good luck!

Maybe you are looking for