ORACLE DATABASE 12c 12.1 Unix AIX,HP-UX,Linux,Solaris and MS Windows Operating Systems

Oracle Database (RDBMS) on Unix AIX,HP-UX,Linux,Solaris and MS Windows Operating Systems Installation and Configuration Requirements Quick Reference (12.1) (Doc ID 1587357.1) To BottomTo Bottom

Oracle 12c on Windows 7

http://blog.mclaughlinsoftware.com/2013/07/26/oracle-12c-on-windows-7/

ebs 12.2. upgrade issue Special Instruction for formsapp.ear Fails When Applying Patch 18186693 During R12.2 Upgrade (Doc ID 1925028.1)

In this Document Symptoms Cause Solution References APPLIES TO: Oracle Applications Technology Stack - Version 12.2 to 12.2 [Release 12.2] Information in this document applies to any platform. SYMPTOMS On : 12.2 version, Upgrade When attempting to apply patch 18186693 per the Upgrade Instruction for R12.2 and following the Readme for 'Special Instruction for formsapp.ear', the following error occurs: ERROR ----------------------- qctapslabapp1$ dcmctl redeployApplication -f $ORACLE_HOME/forms/j2ee/formsapp.ear -a formsapp-co OC4J_BI_Forms ADMN-100001 Error initializing oracle.ias.sysmgmt.utility.RepositoryContext. Resolution: Please make sure the file is in the correct location. Base Exception: java.io.FileNotFoundException /opt/mis/apps/oraApps/APQCTUPG/fs1/inst/apps/APQCTUPG_qctapslabapp1/ora/10.1.2/dcm/config/sysmgmtProperties.dtd (No such file or directory) java.io.FileNotFoundException: /opt/mis/apps/oraApps/APQCTUPG/fs1/inst/apps/APQCTUPG_qctapslabapp1/ora/10.1.2/dcm/config/sysmgmtProperties.dtd (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:138) at java.io.FileInputStream.(FileInputStream.java:97) at oracle.ias.sysmgmt.utility.RepositoryContext.(Unknown Source) at oracle.ias.sysmgmt.utility.RepositoryContext.getInstance(Unknown Source) at oracle.ias.sysmgmt.task.InstanceManager.sysInit(Unknown Source) at oracle.ias.sysmgmt.task.InstanceManager.init(Unknown Source) at oracle.ias.sysmgmt.cmdline.DcmCmdLine.checkInit(Unknown Source) at oracle.ias.sysmgmt.cmdline.DcmCmdLine.execute(Unknown Source) at oracle.ias.sysmgmt.cmdline.DcmCmdLine.main(Unknown Source) The issue can be reproduced at will with the following steps: 1. Review patch 18186693 Readme: ---------------------------------------------------------- SPECIAL INSTRUCTION FOR formsapp.ear --------------------------------------------------------- To complete the application of Patch, please follow these instructions for Application Server middle tier (including Forms/Reports Services): 1. cd $ORACLE_HOME/j2ee/OC4J_BI_Forms/applications/formsapp/formsweb/WEB-INF 2. cp orion-web.xml $ORACLE_HOME/j2ee/OC4J_BI_Forms/applications/orion-web.xml_pre9282569 3. cp web.xml $ORACLE_HOME/j2ee/OC4J_BI_Forms/applications/web.xml_pre9282569 4. Redeploy formsapp by executing the following command: dcmctl redeployApplication -f $ORACLE_HOME/forms/j2ee/formsapp.ear -a formsapp -co OC4J_BI_Forms 5. Restart OC4J_BI_Forms CAUSE This is a known issue for 12.2 release. The issue is caused because of special instructions for formsapp.ear as stated in readme file. These readme instructions are based on a Standalone Forms Server and not a Forms Server used in an Oracle E-Business Suite environment. The SPECIAL INSTRUCTION FOR formsapp.ear is not required for Oracle E-Business Suite Applications. SOLUTION SPECIAL INSTRUCTION FOR formsapp.ear can safely be ignored as this does not pertain to the EBS Applications. These steps can also be ignored for EBS installs. Fusion Middleware patches sometimes have instructions that are not relevant for EBS.

wso2 installation in Windows

https://docs.wso2.com/display/ESB481/Installing+on+Windows Installing on Windows Skip to end of metadata Go to start of metadata Icon Before you begin, please see our compatibility matrix to find out if this version of the product is fully tested on Windows. Follow these instructions to install WSO2 ESB on Windows. Alternatively, you can install it as a Windows service. Installing the required applications Ensure that your system meets the Installation Prerequisites Java Development Kit (JDK) is essential to run the product. Ensure that the PATH environment variable is set to "C:\Windows\System32", because the findstr Windows.exe file is stored in this path. Installing the ESB If you have not done so already, download the latest version of the ESB as described in Downloading the Product. Extract the archive file to a dedicated directory for the ESB, which will hereafter be referred to as . Setting JAVA_HOME You must set your JAVA_HOME environment variable to point to the directory where the Java Development Kit (JDK) is installed on the computer. Typically, the JDK is installed in a directory under C:\Program Files\Java, such as C:\Program Files\Java\jdk1.6.0_27. If you have multiple versions installed, choose the latest one, which you can find by sorting by date. Icon Environment variables are global system variables accessible by all the processes running under the operating system. You can define an environment variable as a system variable, which applies to all users, or as a user variable, which applies only to the user who is currently logged in. You can set JAVA_HOME using the System Properties, as described below. Alternatively, if you just want to set JAVA_HOME temporarily in the current command prompt window, set it at the command prompt. Setting JAVA_HOME using the System Properties 1. Right-click the "My Computer" icon on the desktop and choose Properties. 2. In the System Properties window, click the Advanced tab, and then click the Environment Variables button. 3. Click the New button under "System variables" (for all users) or under "User variables" (just for the user who is currently logged in). 4. Enter the following information: In the "Variable name" field, enter: JAVA_HOME In the "Variable value" field, enter the installation path of the Java Development Kit, such as: c:\Program Files\Java jdk1.6.0_27 5. Click OK. The JAVA_HOME variable is now set and will apply to any subsequent command prompt windows you open. If you have existing command prompt windows running, you must close and reopen them for the JAVA_HOME variable to take effect, or manually set the JAVA_HOME variable in those command prompt windows as described in the next section. To verify that the JAVA_HOME variable is set correctly, open a command window (from the Start menu, click Run, and then type CMD and click Enter) and execute the following command: set JAVA_HOME The system returns the JDK installation path. Setting JAVA_HOME temporarily using the Windows command prompt (CMD) You can temporarily set the JAVA_HOME environment variable within a Windows command prompt window (CMD). This is useful when you have an existing command prompt window running and you do not want to restart it. 1. In the command prompt window, enter the following command where is the JDK installation directory and press Enter: set JAVA_HOME= For example: set JAVA_HOME=c:\Program Files\java\jdk1.6.0_27 The JAVA_HOME variable is now set for the current CMD session only. 2. To verify that the JAVA_HOME variable is set correctly, execute the following command: set JAVA_HOME The system returns the JDK installation path. Setting system properties If you need to set additional system properties when the server starts, you can take the following approaches: Set the properties from a script. Setting your system properties in the startup script is ideal, because it ensures that you set the properties every time you start the server. To avoid having to modify the script each time you upgrade, the best approach is to create your own startup script that wraps the WSO2 startup script and adds the properties you want to set, rather than editing the WSO2 startup script directly. Set the properties from an external registry. If you want to access properties from an external registry, you could create Java code that reads the properties at runtime from that registry. Be sure to store sensitive data such as username and password to connect to the registry in a properties file instead of in the Java code and secure the properties file with the secure vault. You are now ready to run the product.

Understanding SOAP and REST Basics And Differences

http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/ Simple Object Access Protocol (SOAP) and Representational State Transfer (REST) are two answers to the same question: how to access Web services. The choice initially may seem easy, but at times it can be surprisingly difficult. SOAP is a standards-based Web services access protocol that has been around for a while and enjoys all of the benefits of long-term use. Originally developed by Microsoft, SOAP really isn’t as simple as the acronym would suggest. The Difference between SOAP vs REST APIs REST is the newcomer to the block. It seeks to fix the problems with SOAP and provide a truly simple method of accessing Web services. However, sometimes SOAP is actually easier to use; sometimes REST has problems of its own. Both techniques have issues to consider when deciding which protocol to use. Before I go any further, it’s important to clarify that while both SOAP and REST share similarities over the HTTP protocol, SOAP is a more rigid set of messaging patterns than REST. The rules in SOAP are important because without these rules, you can’t achieve any level of standardization. REST as an architecture style does not require processing and is naturally more flexible. Both SOAP and REST rely on well-established rules that everyone has agreed to abide by in the interest of exchanging information. A Quick Overview of SOAP SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet such as the Distributed Component Object Model (DCOM) and Common Object Request Broker Architecture (CORBA). These technologies fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet. After an initial release, Microsoft submitted SOAP to the Internet Engineering Task Force (IETF) where it was standardized. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, and WS-RemotePortlets. In fact, you can find a whole laundry list of these standards on Web Services Standards. The point is that SOAP is highly extensible, but you only use the pieces you need for a particular task. For example, when using a public Web service that’s freely available to everyone, you really don’t have much need for WS-Security. The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually, which becomes problematic because SOAP is intolerant of errors. However, other languages can use shortcuts that SOAP provides; that can help you reduce the effort required to create the request and to parse the response. In fact, when working with .NET languages, you never even see the XML. Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use. One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. Given that you might not own the Web service, this particular feature is extremely important; otherwise you would be left guessing as to why things didn’t work. The error reporting even provides standardized codes so that it’s possible to automate some error handling tasks in your code. An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports. In fact, developers in some languages, such as Python and PHP, are doing just that. A Quick Overview of REST Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform extremely simple tasks because you must create the required XML structure absolutely every time. REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations you must provide additional information in special ways, but most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP 1.1 verbs (GET, POST, PUT, and DELETE) to perform tasks. Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application. As an example of working with REST, you could create a URL for Weather Underground. The API’s documentation page shows an example URL of http://api.wunderground.com/api/Your_Key/conditions/q/CA/San_Francisco.json. The information you receive in return is a JSON formatted document containing the weather for San Francisco. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application. Deciding Between SOAP and REST Before you spend hours fretting over the choice between SOAP and REST, consider that some Web services support one and some the other. Unless you plan to create your own Web service, the decision of which protocol to use may already be made for you. Extremely few Web services, such as Amazon, support both. The focus of your decision often centers on which Web service best meets your needs, rather than which protocol to use. Soap Vs Rest SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST: Language, platform, and transport independent (REST requires use of HTTP) Works well in distributed enterprise environments (REST assumes direct point-to-point communication) Standardized Provides significant pre-build extensibility in the form of the WS* standards Built-in error handling Automation when used with certain language products REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP: No expensive tools require to interact with the Web service Smaller learning curve Efficient (SOAP uses XML for all messages, REST can use smaller message formats) Fast (no extensive processing required) Closer to other Web technologies in design philosophy Locating Free Web Services The best way to discover whether SOAP or REST works best for you is to try a number of free Web services. Rolling your own Web service can be a painful process, so it’s much better to make use of someone else’s hard work. In addition, as you work with these free Web services you may discover that they fulfill a need in your organization, and you can save your organization both time and money by using them. Here are some to check out: Free-Web-Services.com WebserviceX.NET SwaggerHub XMethods One common concern about using a free Web service is the perception that it could somehow damage your system or network. Web services typically send you text, not scripts, code, or binary data, so the risks are actually quite small. Of course, there’s also the concern that Web services will disappear overnight. In most cases, these Web services are exceptionally stable and it’s unlikely that any of them will disappear anytime soon. I’ve been using some of them now for five years without any problem. However, stick with Web services from organizations with a large Internet presence. Research the Web service before you begin using it. Working with the Geocoder Web Service To make it easier to understand how SOAP and REST compare, I decided to provide examples of both using the same free Web service, geocoder.us (thank you to Mark Yuabov for suggesting it). This simple Web service accepts an address as input and spits out a longitude and latitude as output. You could probably mix it with the Google Maps API example I present in “Using the Google Maps API to Add Cool Stuff to Your Applications.” Viewing a Simple REST Example Sometimes, simple is best. In this case, REST is about as simple as it gets because all you need is an URL. Open your browser—it doesn’t matter which one—and type http://rpc.geocoder.us/service/csv?address=1600+Pennsylvania+Ave,+Washington+DC in the address field. Press Enter. You’ll see the output in your browser in CSV format: You see the latitude, followed by the longitude, followed by the address you provided. This simple test works for most addresses in most major cities (it doesn’t work too well for rural addresses, but hey, what do you expect for free?). The idea is that you obtain the latitude and longitude needed for use with other Web services. By combining Web services together with a little glue code, you can create really interesting applications that do amazing things in an incredibly short time with little effort on your part. Everyone else is doing the heavy lifting. You can also test your REST API with simple to use tools like SoapUI. Explaining a Simple SOAP Example SOAP, by its very nature, requires a little more setup, but I think you’ll be amazed at how simple it is to use. Begin this example by creating Windows Forms application using Visual Studio. The sample code uses C#, but the same technique works fine with other .NET languages (you’ll need to modify the code to fit). Add labels, textboxes, and buttons as shown here (the Latitude and Longitude fields are read-only). Here’s where the automation comes into play. Right click References in Solution Explorer and choose Add Service Reference from the context menu. You’ll see the Add Service Reference dialog box. Type the following address into the address field: http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl and click Go. Type GeocoderService in the namespace field. Your dialog box should look like the one shown here. Click OK. Visual Studio adds the code needed to work with Geocoder in the background. At this point, you’re ready to use the Web service. All you need to do is to add some code to the Get Position button as shown here. private void btnGetPosition_Click(object sender, EventArgs e) { // Create the client. GeocoderService.GeoCode_PortTypeClient Client = new GeocoderService.GeoCode_PortTypeClient(); // Make the call. GeocoderService.GeocoderResult[] Result = Client.geocode(txtAddress.Text); // Check for an error result. if (Result != null) { // Display the results on screen. txtLatitude.Text = Result[0].lat.ToString(); txtLongitude.Text = Result[0].@long.ToString(); } else { // Display an error result. txtLatitude.Text = "Error"; txtLongitude.Text = "Error"; } } The code begins by creating a client. This is a common step for any Web service you use with Visual Studio (or other environments that support SOAP natively). To see another version of the same step, check out the PHP example. After you create the client, you use it to call one of the methods supported by the Web service. In this case, you call geocode() and pass the address you want to work with. The result of the call is stored in a GeocoderResult variable named Result. A single address could possibly end up providing multiple positions if you aren’t specific enough, so this information is passed back as an array. Let’s assume that no errors occur (resulting in a null return value). The example assumes that you provided great information, so it places the information found in the first Result entry into the Latitude and Longitude output. So, this example isn’t really that complicated compared with REST, but as you can see, even a simple example is more work. The Bottom Line: When To Use SOAP Or REST Some people try to say that one process is better than the other, but this statement is incorrect. Each protocol has definite advantages and equally problematic disadvantages. You need to select between SOAP and REST based on the programming language you use, the environment in which you use it, and the requirements of the application. Sometimes SOAP is a better choice and other times REST is a better choice. In order to avoid problems later, you really do need to chart the advantages and disadvantages of a particular solution in your specific situation. There’s one absolute you should get from this article. Don’t reinvent the wheel. It’s amazing to see companies spend big bucks to create Web services that already exist (and do a better job than the Web service the company creates). Look for free alternatives whenever possible. In many cases, the choice of Web service also determines your choice of protocol. Actually there are two. Whether you pick between SOAP or REST for your web service, making sure you thoroughly test your APIs. Ready! API has a full suite of functional, performance, security and virtualization tools for your API testing needs. You can also learn how to test RESTful APIs, in our API Testing Resource center