LAKSHMI WEBLOGIC/SOA ADMIN

The procedures on this page are for new installations of Jenkins on a single/local machine. Jenkins is typically run as a standalone application in its own process with the built-in  Java servlet  container/application server ( Jetty ). Jenkins can also be run as a servlet in different Java servlet containers such as  Apache Tomcat  or  GlassFish . However, instructions for setting up these types of installations are beyond the scope of this page. Note:  Although this page focusses on local installations of Jenkins, this content can also be used to help set up Jenkins in production environments. Prerequisites Minimum hardware requirements 256 MB of RAM 1 GB of drive space (although 10 GB is a recommended minimum if running Jenkins as a  Docker  container) Recommended hardware configuration for a small team 1 GB+ of RAM 50 GB+ of drive space Sofware requirements: Java 8 - either a Java Runtime Environment (JRE) or a ...

Jenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software. Jenkins can be installed through native system packages, Docker, or even run standalone by any machine with a Java Runtime Environment (JRE) installed. Getting Started with the Guided Tour.   Prerequisites: Download and run Jenkins A machine with: 256 MB of RAM, although more than 512MB is recommended 10 GB of drive space (for Jenkins and your Docker image) The following software installed: Java 8 (either a JRE or Java Development Kit (JDK) is fine) Docker (navigate to  Get Docker  at the top of the website to access the Docker download that’s suitable for your platform) STEPS FOR INSTALLATION: Download Jenkins. Open up a terminal in the download directory Run  java -jar jenkins.war --httpPort=8080 . Browse to  http://localhost...

connect('weblogic', 'weblogic', 't3://localhost:7003') serverRuntime() cd('/JMSRuntime/MS1.jms/JMSServers/dizzyworldJMSServer/Destinations/DizzyworldJMSModule!dizzyworldqueue') cmo.deleteMessages('')

Using WLST (WebLogic Scripting Tool): connect('weblogic', 'current_password', 't3://localhost:7001') edit() startEdit() # Change password for user 'testuser' cd('/SecurityConfiguration/mydomain/Realms/myrealm/Users/testuser') cmo.setPassword('new_password') save() activate() exit() Script Mode: Save as  passwordchange.py  and run with  wlst.sh passwordchange.py : username = 'weblogic'  # Admin username old_password = 'old_password'  # Current password new_password = 'new_password'  # New password admin_url = 't3://localhost:7001'  # Admin server URL target_user = 'testuser'  # User whose password to change try:     connect(username, old_password, admin_url)     edit()     startEdit()     # Navigate to user in security realm     cd('/SecurityConfiguration/mydomain/Realms/myrealm/Users/' + target_user)     cmo.setPassword(new_password)     save()     activate()   ...

connect('weblogic','weblogic','t3://localhost:7001') serverConfig() cd('/SecurityConfiguration/base_domain/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator') cmo.createUser('pavan','pavan123',"") cmo.addMemberToGroup('Administrators','pavan') disconnect() exit()

Open nodemanager.properties file which is located at /home/bea/weblogic91/common/nodemanager  and change the below entry SecureListener=false Loging to console :  Navigate to Machines->Machine-1->Node Manager-> Type : Plain Step 1) cd /home/bea/weblogic92/common/bin            ./wlst.sh Step 2) Start Node manager :            i) /home/bea/weblogic92/server/bin/startNodeManager.sh             or            ii)  startNodeManager(verbose='true', NodeManagerHome='/home/bea/weblogic92/common/nodemanager',ListenPort='5556', ListenAddress='localhost') Step 3) Connect to Nodemanager         wls:/offline> nmConnect('weblogic', 'weblogic', 'localhost', '5556', 'dev_domain','/home/bea/user_projects/domains/dev_domain','plain') Connect...

connect('weblogic','weblogic','t3://localhost:7001') domainRuntime() cd('ServerRuntimes') servers=domainRuntimeService.getServerRuntimes() for server in servers:         serverName=server.getName();         print '**************************************************\n'         print '##############   ',serverName,    '###############'         print '**************************************************\n'         print '##### Server State           #####', server.getState()         print '##### Server ListenAddress   #####', server.getListenAddress()         print '##### Server ListenPort      #####', server.getListenPort()  ...

1. Dynamic Domain Creation Using Python Dictionaries (Unique Approach) Why?  Avoid hardcoding values—use a reusable JSON/YAML-style structure. WLST Script ( createDomain_advanced.py ) # Define domain config as a dictionary (modular & editable) domain_config = {     "domain_name": "ProdClusterDomain",     "admin_user": "weblogic",     "admin_password": "S3cr3t#123",  # Encrypt in production!     "java_home": "/usr/java/jdk1.8.0_301",     "listen_address": "10.0.0.100",     "listen_port": 7001,     "clusters": [         {"name": "ProdCluster", "multicast": "239.192.0.1", "servers": 4}     ],     "data_sources": {         "jdbc/AppDS": {             "url": "jdbc:oracle:thin:@db-host:1521/ORCL",             "driver": "oracle.jdbc.OracleDriver"         }     } ...

print "deployed application status" connect('weblogic','weblogic','t3://localhost:8001') print "**************Deployed application status****************" ls('AppDeployments') print "*********************************************************" disconnect() exit()

./wlst.sh undeploy.py connect('weblogic','weblogic','t3://localhost:8001') print "undeploying application........." undeploy('benefits') print "........................." disconnect() exit()

deploy.py  print '***********************************************************************' connect('weblogic','weblogic','t3://localhost:7001') print '***********************************************************************' edit() print '***********************************************************************' startEdit() print '***********************************************************************' print '***********************************************************************' deploy('benefits','/home/application/benefits.war',targets="ms1,ms2") print '***********************************************************************' save() print '***********************************************************************' activate() print '***********************************************************************' disconnect()

The message itself is simply some sort of data structure—such as a string, a byte array, a record, or an object. It can be interpreted simply as data, as the description of a command to be invoked on the receiver, or as the description of an event that occurred in the sender. Sender can send a  Command Message , specifying a function or method on the receiver that the sender wishes to invoke. It can send a  Document Message , enabling the sender to transmit one of its data structures to the receiver. Or it can send an  Event Message , notifying the receiver of a change in the sender.  The following message type patterns can commonly be used in SOA.  .  Messaging Channel Patterns Channels, also known as queues, are logical pathways to transport messages. A channel behaves like a collection or array of messages, but one that is magically shared across multiple computers and can be used concurrently by multiple applications.  A service provider is ...