This is an overview about PeopleSoft COBOL in case you come to touch with this part in PeopleSoft. Many of PeopleSofts business process are written in COBOL. And, you should be really cautious before modifying this part. And peoplesoft gives you a good advice on that.
All the database activity is processed through a module called PTPSQLRT. SQL statements are stored in a database table andd executed by passing the statement name and associated parameters to the PTPSQLRT module.
All peoplesoft COBOL programes use the same structured approach. there is no direct database access using embedded sql. All SQL statements to be executed reside in database called PS_SQLSTMT_TBL. This SQL statement table is populated by using a set of DataMover scripts.The key behind PeopleSoft's structured approach is the use of the main module called PTPSQLRT.This module ensures consistancy regardless of platform/database.
The PTPSQLRT module variety of functions:
Execute select statements
fetched rows from database
processes SQL updates
Commits and Rollbacks
Connect/Disconnect from Database stc..
Even if you dont plan on modifying COBOL programs, become familiar with PeopleSoft's COBOL techniques. This will be surely be times when you need to browse the COBOL source code when troubleshooting.
I would recommend the book, essential guide to PeopleSoft development and customization to know about COBOL technically.
So have a look into PeopleSoft COBOL side...it is interesting.
http://en.wikipedia.org/wiki/COBOL would be a starting point for an overview in programming. And the birth story behind this is another interesting part. Read on...
Anoop Savio
Thursday, February 25, 2010
Friday, February 19, 2010
Import/Export WebService
Export Message Schema
set log c:\Temp\webservice_qac\PSIBMSGSCHEMA_EXP.log;
set output c:\Temp\webservice_qac\PSIBMSGSCHEMA_EXP.dat;
export PSIBMSGSCHEMA
WHERE MSGNAME IN ('M113977','M384127','M484624',' M580849','M594368','M626443') AND APMSGVER = 'V1';
Export WebService
set log c:\Temp\webservice_qac\PSIBWSDL_EXP_Web_Services.log;
set output c:\Temp\webservice_qac\PSIBWSDL_EXP_Web_Services.dat;
export PSIBWSDL
WHERE IB_WSDLNAME in ('CI _PI_JOB_V2.1');
Import message
SET INPUT c:\Temp\webservice_qac\PSIBMSGSCHEMA_EXP.dat;
SET LOG c:\Temp\webservice_qac\PSIBMSGSCHEMA_IMP.LOG;
set no record;
delete from PSIBMSGSCHEMA
WHERE MSGNAME IN ('M113977','M384127','M484624',' M580849','M594368','M626443') AND APMSGVER = 'V1';
import *;
Import WSDL
SET INPUT c:\TEMP\webservice_qac\PSIBWSDL_EXP_Web_Services.dat;
SET LOG c:\TEMP\webservice_qac\PSIBWSDL_EXP_Web_Services.log;
set no record;
delete from PSIBWSDL
WHERE IB_WSDLNAME in ('CI_PI_JOB_V2.1');
import *;
Anoop Sasikala
Sunday, February 7, 2010
Why UDDI Is Important
Attempting to create a Service Oriented Enterprise without a Service Registry is destined for trouble; here is how UDDI can help
Web Services are a great advance in our quest for the Service Oriented Enterprise, but most enterprises overlook the importance of a Service Registry (UDDI). This article outlines reasons why UDDI is critical to successful SOA initiatives and reviews recent enhancements to the UDDI standard.
What is a Service Registry?
A service registry is a central repository that allows for the cataloging of services throughout the enterprise. This catalog provides service consumers a place to search for details about service providers, the functional areas (taxonomies) these services address and binding details (location, contract, transport, etc.) for services.
The analogy often used is that of the telephone directory, but I think DNS (Domain Name System) is also a good fit. DNS is something we all understand at least at some level. DNS helps us as humans find computers which only know each other as IP Addresses (numbers). There is a similar parallel with a service registry. Service registries help us as service consumers (people) find services in a simple and centralized manner. They go one step further, however, and help consumers (programs) know how specifically to communicate with them as well.
UDDI
Universal Description Discovery and Integration (UDDI) is the accepted standard for service registries in the SOA context. It is now in its third version and has added important features that really make it the only practical choice for service registry. There are many UDDI servers (i.e. products) available; every large software vendor produces one. There are also many open source servers available as well. The good news is that they mostly implement the entire specification; even the free ones.
Continuing the telephone directory analogy, UDDI consists of three types of directories:
• White Pages – which identify organizations (companies, or more likely departments)
• Yellow Pages – which categorize services (like AP, Purchase Order, etc)
• Green Pages – bindings or details for specific services
The three pages represent a hierarchy--presented above from top down. One organization may (and should) have multiple categories of services, each with multiple service binding options.
Why use the Registry?
The registry really addresses many problems inherent in the enterprise: namely communication and responsibility (ownership). The existence of a registry allows others in the enterprise to see who (person or department) owns a service and who can be contacted for further details as well as where this service exists and how to communicate with it on a technical level (more on this last part later).
The ownership part is critical and it starts off by making the service landscape more open and transparent. I have worked with clients large and small that inadvertently created duplicate services (or worse yet skipped the service that existed and went directly to the data source) because they were unaware of services existing to perform tasks they needed. This is not only a major lapse in communication, but also in governance.
In addition to existence, ownership can be easily and clearly established. Services are like middleware in that they don’t have a User Interface that management sees and is reminded about. Being autonomous by nature it is possible for services to simply run for years without anyone really being responsible for them. This is a mistake because when there are problems consumers won’t know where to turn for help. Ownership in the registry removes this ambiguity and helps keep a clean line of communication between providers and consumers (the people, not the programs in this case).
From an operational standpoint the registry allows service providers to publish secondary versions of their services to be used for testing, disaster recovery, and the like. This creates more fluidity and provides better certainty in service capabilities for users. Critically, it also allows providers to change the location of their services dynamically. When used properly a service consumer does not directly reference a service address, but instead queries UDDI and uses the resulting service information to communicate with the service. It is this level of directory indirection that makes UDDI operationally so powerful.
Many companies rely on DNS, router, or client configuration updates to facilitate moving services. This last part is really the most damning. If your consumer applications need to change for something as simple as a service location change then you are clearly violating core principles of Service Orientation. Alas this is the missing link in most enterprises’ foray into Service Orientation: without UDDI most efforts simply result in point to point service calls. As the web of services grows their manual management becomes a burden too great to sustain.
IT and SOA Governance get a lot of attention today and in many ways they tie to the concepts discussed above about ownership and existence. The last critical piece of the registry trifecta comes from requiring all services to be listed in the registry, and requiring consumers to use the registry. Once that’s accomplished service governance becomes a very simple affair. In fact, subscriptions in UDDI v3 allow for governance notifications when any aspect of the registry changes. This can be details of a service binding or transport, changes to a contract, or even just changes to the human contact information.
Why do so many people hate UDDI?
In part UDDI was a victim of technology marketing hype (indeed much like SOA nearly was). The major vendors (including IBM, Microsoft and SAP) all created public registries for web services believing (or trying to mandate) that companies would make many services publically accessible and searchable. There was an effort to push UDDI as a sort of DNS and Search Engine for web services. That this did not materialize in the manner first imagined should be no surprise. When UDDI hit the world there had not yet been a standardized security approach (WS-Security). This would make a public exchange of services troublesome to say the least. Yet many successful technologies flourish in applications other than their original intention.
Hurting UDDI further were a heavy use of Universally Unique Identifiers (UUIDs) which are great for computers, but terrible for people, as well as a less flexible taxonomy (both issues which have been rectified in the newest versions). UDDI was pushed, it seems, as some sort of external service to facilitate exchange between companies. In my experience UDDI fits much better in the internal role providing registry and governance capabilities to the enterprise itself.
How can an enterprise start being successful with UDDI?
The first place enterprises can begin succeeding is by simply starting to use UDDI and to mandate its centralized use and administration. Although global adoption is the best way, even one department using it is a good start. Critically, using Web Services in a point to point manner must stop. All web service access should be performed using UDDI lookups
UDDI should be leveraged to provide visibility into service existence, ownership, and technical implementation. By searching categories (taxonomies) developers or managers will be able to plan projects knowing what services exist to aid development. When gaps are found and services must be created they should embrace the concepts of SOA and create a true reusable service rather than just a point to point solution. This service should then be entered into the registry. The beautiful thing about UDDI and SOA in general is that even if you start with one type of UDDI server you should be able to switch between vendors quite easily.
Important changes in UDDI v3
The virtue of UDDI has been made even more attractive by smart revisions to the UDDI standard. The latest version of UDDI introduces some critically important features, some of which have already been introduced.
The following features will be presented in more detail in future articles:
• Multi-Registry support (making UDDI function even more like DNS).
• Support for digital signatures to verify the validity of registry entries.
• Expanded query support.
• Subscription API.
Conclusion
We have seen what UDDI can provide us as well as how it has changed recently. We covered how existence and ownership being visible and open helps an enterprise better manage and plan its service assets. We also covered how the registry can allow the changing of service details (like address) without changes to consumers. When we think of what Service Registry/UDDI can do for our enterprise, the choice should be clear. UDDI is not a luxury, but a necessity for web services in general and Service Orientation in particular.
Source CIO.com
Web Services are a great advance in our quest for the Service Oriented Enterprise, but most enterprises overlook the importance of a Service Registry (UDDI). This article outlines reasons why UDDI is critical to successful SOA initiatives and reviews recent enhancements to the UDDI standard.
What is a Service Registry?
A service registry is a central repository that allows for the cataloging of services throughout the enterprise. This catalog provides service consumers a place to search for details about service providers, the functional areas (taxonomies) these services address and binding details (location, contract, transport, etc.) for services.
The analogy often used is that of the telephone directory, but I think DNS (Domain Name System) is also a good fit. DNS is something we all understand at least at some level. DNS helps us as humans find computers which only know each other as IP Addresses (numbers). There is a similar parallel with a service registry. Service registries help us as service consumers (people) find services in a simple and centralized manner. They go one step further, however, and help consumers (programs) know how specifically to communicate with them as well.
UDDI
Universal Description Discovery and Integration (UDDI) is the accepted standard for service registries in the SOA context. It is now in its third version and has added important features that really make it the only practical choice for service registry. There are many UDDI servers (i.e. products) available; every large software vendor produces one. There are also many open source servers available as well. The good news is that they mostly implement the entire specification; even the free ones.
Continuing the telephone directory analogy, UDDI consists of three types of directories:
• White Pages – which identify organizations (companies, or more likely departments)
• Yellow Pages – which categorize services (like AP, Purchase Order, etc)
• Green Pages – bindings or details for specific services
The three pages represent a hierarchy--presented above from top down. One organization may (and should) have multiple categories of services, each with multiple service binding options.
Why use the Registry?
The registry really addresses many problems inherent in the enterprise: namely communication and responsibility (ownership). The existence of a registry allows others in the enterprise to see who (person or department) owns a service and who can be contacted for further details as well as where this service exists and how to communicate with it on a technical level (more on this last part later).
The ownership part is critical and it starts off by making the service landscape more open and transparent. I have worked with clients large and small that inadvertently created duplicate services (or worse yet skipped the service that existed and went directly to the data source) because they were unaware of services existing to perform tasks they needed. This is not only a major lapse in communication, but also in governance.
In addition to existence, ownership can be easily and clearly established. Services are like middleware in that they don’t have a User Interface that management sees and is reminded about. Being autonomous by nature it is possible for services to simply run for years without anyone really being responsible for them. This is a mistake because when there are problems consumers won’t know where to turn for help. Ownership in the registry removes this ambiguity and helps keep a clean line of communication between providers and consumers (the people, not the programs in this case).
From an operational standpoint the registry allows service providers to publish secondary versions of their services to be used for testing, disaster recovery, and the like. This creates more fluidity and provides better certainty in service capabilities for users. Critically, it also allows providers to change the location of their services dynamically. When used properly a service consumer does not directly reference a service address, but instead queries UDDI and uses the resulting service information to communicate with the service. It is this level of directory indirection that makes UDDI operationally so powerful.
Many companies rely on DNS, router, or client configuration updates to facilitate moving services. This last part is really the most damning. If your consumer applications need to change for something as simple as a service location change then you are clearly violating core principles of Service Orientation. Alas this is the missing link in most enterprises’ foray into Service Orientation: without UDDI most efforts simply result in point to point service calls. As the web of services grows their manual management becomes a burden too great to sustain.
IT and SOA Governance get a lot of attention today and in many ways they tie to the concepts discussed above about ownership and existence. The last critical piece of the registry trifecta comes from requiring all services to be listed in the registry, and requiring consumers to use the registry. Once that’s accomplished service governance becomes a very simple affair. In fact, subscriptions in UDDI v3 allow for governance notifications when any aspect of the registry changes. This can be details of a service binding or transport, changes to a contract, or even just changes to the human contact information.
Why do so many people hate UDDI?
In part UDDI was a victim of technology marketing hype (indeed much like SOA nearly was). The major vendors (including IBM, Microsoft and SAP) all created public registries for web services believing (or trying to mandate) that companies would make many services publically accessible and searchable. There was an effort to push UDDI as a sort of DNS and Search Engine for web services. That this did not materialize in the manner first imagined should be no surprise. When UDDI hit the world there had not yet been a standardized security approach (WS-Security). This would make a public exchange of services troublesome to say the least. Yet many successful technologies flourish in applications other than their original intention.
Hurting UDDI further were a heavy use of Universally Unique Identifiers (UUIDs) which are great for computers, but terrible for people, as well as a less flexible taxonomy (both issues which have been rectified in the newest versions). UDDI was pushed, it seems, as some sort of external service to facilitate exchange between companies. In my experience UDDI fits much better in the internal role providing registry and governance capabilities to the enterprise itself.
How can an enterprise start being successful with UDDI?
The first place enterprises can begin succeeding is by simply starting to use UDDI and to mandate its centralized use and administration. Although global adoption is the best way, even one department using it is a good start. Critically, using Web Services in a point to point manner must stop. All web service access should be performed using UDDI lookups
UDDI should be leveraged to provide visibility into service existence, ownership, and technical implementation. By searching categories (taxonomies) developers or managers will be able to plan projects knowing what services exist to aid development. When gaps are found and services must be created they should embrace the concepts of SOA and create a true reusable service rather than just a point to point solution. This service should then be entered into the registry. The beautiful thing about UDDI and SOA in general is that even if you start with one type of UDDI server you should be able to switch between vendors quite easily.
Important changes in UDDI v3
The virtue of UDDI has been made even more attractive by smart revisions to the UDDI standard. The latest version of UDDI introduces some critically important features, some of which have already been introduced.
The following features will be presented in more detail in future articles:
• Multi-Registry support (making UDDI function even more like DNS).
• Support for digital signatures to verify the validity of registry entries.
• Expanded query support.
• Subscription API.
Conclusion
We have seen what UDDI can provide us as well as how it has changed recently. We covered how existence and ownership being visible and open helps an enterprise better manage and plan its service assets. We also covered how the registry can allow the changing of service details (like address) without changes to consumers. When we think of what Service Registry/UDDI can do for our enterprise, the choice should be clear. UDDI is not a luxury, but a necessity for web services in general and Service Orientation in particular.
Source CIO.com
Monday, February 1, 2010
Creating Directory under PSHOME
This code is for Creating Directory under the environment variable PSHOME, which is instance indsependent.
XMLP using PS Query Source
This code explains the usage of PSQuery as datasource. The report is generated in the appserver and it is transferred to the FTP path prior to displaying it.
Code for Attachment Launch
This is the code for Launching the attachment with the filename captured from the attachment table.
One way for Avoiding SQLEXEC usuage
How to mitigate the performance issues because of using a sqlexec while coding? the simple answer is avoid using it.
Consider we have an sqlexec which will be executed in a loop several times, as shown in the first screenshot. Using stanalone rowset/record creation can solve this problem to an extent.
The second screen shot shows a simple way to replace the first sqlexec statement. It wont look great, but it can contribute towards the performance of your applicantion.
Subscribe to:
Posts (Atom)