I am completely new to SAP netweaver in fact SAP. I am working in a project which is based on Java/J2ee(JSF, Icefaces) and SAP netweaver combination. Currently, we are building/deploying the application using ant, for every small change in jspx file or some html file, we have do re-build.
Just wanted to know, if I can browse the deployment location like other application servers(Jboss,tomcat,weblogic) and manually deploy the respective changed file. Any possibility.
Does it have hot deployment. I am using SAP J2EE engine/7.00.
Any ideas or approach to make it quickly deploy.
You can update JSPs, html, and those type of resources by copying them directly into the web app's working directory. Mine, for example, is /usr/sap/(sid)/J00/j2ee/cluster/apps/(vendor)/(appname)/servlet_jsp/(webapp_root)/root/(your jsps are here).
Note, however, that you will lose those changes if you restart the app server instance because it will reload your application from the database.
Related
I am working on customizing the oracle service cloud customer portal, but since OSvC provides only WebDAV to connect to it. It is very time-consuming to edit files and then upload them to WebDAV even for a single word change.
I am looking for a solution to serve it locally make desired changes and then upload the desired code to webDEV.
But after searching the file structure I can not make which framework it uses, I tried to use websites like https://builtwith.com/ and WhatRuns but they are also not able to find anything useful.
Although after searching in the file structure, I find some files of CodeIgnitor but the structure is way more different than the CodeIgnitor folder structure.
The short answer is no, you will not be able to run Customer Portal locally. While it is a fork of CodeIgniter from many years ago, there are server-side dependencies that will prevent you from running it in a local sandbox.
That said, it is possible to automate many of the manual tasks of interacting with WebDAV for change testing. If you edit locally, then you can use scripting hooks or event RPA robots to automate some of the manual file movement. Personally I have a flow to edit remotely in my test environment with an editor (like VSCode or Nova) that can connect to a remote server via WebDAV and edit files directly in the development area of a site. Then, when finished, I have a script that pulls down the latest version of all files and then allows me to commit changes to Git for SCM.
Another option is RPA. You can develop a robot that can be run to automate the manual tasks that you face in your workflow. Personally, I think that scripting is a better solution than RPA since you can automate all of the actions via scripting or a shell. But, it's another option to consider.
Another way of "Live editing" the OSvC CP code is to connect to WebDav via a software that supports it like Mountain Duck which uploads your code to OSvC on save.
OR use the better solution Windows Explorer which supports connecting to WebDav and treating it like a network drive, by going on My Computer -> Computer -> Map Network Drive then put https://yoursite.custhelp.com/dav/cp click Next then you'll be promoted to login using your OSvC login.
I want to deploy on IIS my web site but I do not want to take whole project. I just need to take .dll file. Is their any way to do so.
I do not want to use visual studio only .dll file from the project to deploy.
The basic steps for deploying to IIS on windows server are as follows:
log onto the machine that is or will be hosting your application.
Use IIS Manager to create a new website for your application.
Create a new application in that site. I believe this also will automatically create an application pool with the same name for you and use it by default.
Specify the virtual directory for your application. This is going to tell IIS where to look for your mvc application. For this case lets assume it is C:\myApp
On your own machine Build the application however you build it with the correct solution configuration (i.e. Release mode). Let say the result of your build is located at C:\MyProject\bin
Copy C:\MyProject\bin from your machine onto your hosting machine at C:\myApp
You should be able to search these steps and find a step by step guide of how to accomplish them. Here is a link to some info on what sites, applications and app pools are to help you better understand.
http://www.iis.net/learn/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis
Based on your sites requirements there will be some additional steps to set up security and alter bindings if you need to change them.
You don't need to deploy your entire website if you only make a change in a single assembly. You could copy the .DLL assembly directly to the bin folder of your website. This will trigger the Application Pool to be recycled in IIS and the changes will be taken into effect on the next request.
I'll be using RTC in the near future here at work. My question is: where does it put the files the team members will be working on? I understand that each programmer will work on the projects files and they will push the changes to the main repository. We have a local web server where we test our work (php). So, do we have to configure RTC to publish the files to the web server? or the RTC server must be installed in the webserver so it can save the files?
We use Rational Team Concert almost exactly as you describe, and it works brilliantly. My small team of web developers collaborates on website source code and delivers it to two different streams depending on its readiness: production-stream and staging-stream. Then we have defined two builds that check out the source code, move some things around, and push the files to the web servers via SCP. So, with a few clicks we kick off a staging build, watch it finish in about two minutes and everyone can see the changes on the staging server. When the code is ready for prime-time, the change sets are delivered to production-stream and the production build is kicked off, which is configured to copy the files to the production web server.
But even before a staging or production build is run, any of us can simply configure a local web server in RTC using the Eclipse PDE and Web Tools add-ons and see the site running in localhost as we develop.
All our work is done within Rational Team Concert, from planning, to bug tracking, to source control, to builds. It's very well-suited for website management.
Your understanding is correct - you work on files locally, and they get uploaded on to the server when you checkin. Bear in mind that checkin in RTC terms really means back-up your files to the server, it is a Deliver command that shares the files with others (it is worth a quick look at the articles on jazz.net that explains how SCM works).
One way to pubish to your php server is to make that part of a build, or a build in its own right (which RTC also handles - in conjunction with your favourite build tool). The build would copy the files to the php server. The advantage of doing this as a build is you will know exactly what versions of your files are being copied, and you will be able to reproduce this copy at any point in the future.
You do not need to install the RTC server on the php server.
You can also try posting on the forums on http://jazz.net/ if you have questions on RTC.
Hope that helps.
Another alternative would be to use the command line interface to accept all changes into a workspace and run that with a cron job.
To handle discarded change sets, you'd probably want to use something like:
scm workspace replace-components <workspace-name> stream <uuid-of-stream> --all
after you had initially loaded the workspace on your web server.
Want to build a plug-in for Eclipse that provides custom features, as required by our project and is able to persist the data (provide client server capabilities). Please suggest options.
Have a look a this http://www.eclipse.org/articles/Article-Your%20First%20Plug-in/YourFirstPlugin.html
and this
http://www.eclipsepluginsite.com/
This is a tad old but should still work : http://sourceforge.net/projects/jalcedo2
'JALCEDO is Rich Client Java Application develpment environment with database management tool accessible to create and modify database from client PC via http network based on Eclipse RCP. It support multiple database, including PostgreSQL and MySQL.'
Note that some of the code of this framework is now part of Eclipse DTP
I'm looking for suggestions on keeping a program that is running on a network updated. Installation consists of 15 users, each have the program on their local pc, but they all access same date from sql server.
I am looking for a clean method that would allow me to update one folder on the network and for each computer to get updated when they run the program and the programs sees a later ver on that folder on the network. (Obviously I can do this inside the program itself since it won't allow being overwritten while opened.)
You should have a look at
ClickOnce is a deployment technology
that enables self-updating
Windows-based applications that can be
installed and run with minimal user
interaction.
Using ClickOnce Deployment in
VB.NET
ClickOnce - A new VB.NET 2005 Deployment Tool
ClickOnce Deployment for Windows Forms Applications
ClickOnce Deployment in .NET Framework 2.0
Another option is to create a second program that will check the network for an updated version of your application. Let's call this program "updater.exe".
You can run updater.exe on system startup like Adobe Reader or Sun Java do.
Or, when your application is started it can load updater.exe. If updater.exe finds an update, it can close/unload your application, download the newer version, restart your application and close itself.
astander's answer above is correct, you can use ClickOnce for this. Another option is creating this application as a web application.
Web applications basically work the way you described, the application's files reside in a web server, all the users connect to it using a browser, and to update the application you only need to update the files in the server.