Navya Technologies

07/05/2017

This day will be remembered in the Indian Cinema History. Thank you all for your great support..🙏🙏🙏

02/02/2017

10/12/2016

good morning you all

04/12/2016

Good morning...

29/12/2015

Building Blocks of Integration Broker

Nodes
If you think about the e-mail analogy, the Node would be like the Domain part of the e-mail addresses. For PeopleSoft-to-PeopleSoft communication, Nodes are (usually) PSFT_EP for Financials, PSFT_HR for HRMS, PSFT_LM for LMS, and PSFT_CRM for CRM. They basically tell which application a message belongs to.

The node definition is where you define what messages are valid for that node. Prior to PeopleTools 8.48, you’d define them on the “Transaction” tab. In 8.48 and above, you’d define them on the “Routings” tab.

Since you might not want just anybody being able to publish a message to a node, you’ll need to set a node password on the first page of the node definition. This password will have to be the same in all of the environments. For example, if you want to publish a message to PSFT_EP from HRMS, the PSFT_EP node password will have to be the same in both Financials and HRMS.
Messages
The message definition is where the developer specifies what data a message will contain. It includes records and fields, and child records are nested under their parent records.

If you think of the e-mail analogy, the message name would be both the User part of the e-mail address, and the message itself would be the Body of the e-mail.
Transformations
A transformation is a program that gets executed against a message either when it’s sent, or when it’s received. If you think about it, this can be important because data structures are different with different PeopleSoft versions. So if you’re sending a message with employee data from HRMS 8.8 back to Financials version 8.4, there’s a good chance that the message that HRMS sends is different from what Financials is able to receive. So you need a transformation.

The transformation itself is a special type of Application Engine program that integration broker can execute by itself against the XML of a message. It uses either PeopleCode, or XSLT (a special language for transforming XML) to put the message into the new format.

In the e-mail analogy, this would be like me sending an e-mail to someone who doesn’t speak English. I'd either have to translate it before I sent it, or the recipient would have to translate it.

Prior to PeopleTools 8.48, you use “Relationships” to associate a Transformation program to a message. In 8.48 and above, you can associate a Transformation to a Message with either a Service Operation or a Routing.
Gateways
The gateway is kind of like the e-mail server. It knows the nodes – that is to say for a given node it knows the server name, app server port number, username and password so that it can connect to the node’s app server and push the message to the integration broker running in that environment.

The gateway runs as part of the PIA web server. Integration Broker sends messages to it with a plain ‘ol Post HTTP request. This makes talking to Integration Broker pretty easy for 3rd party applications since they don’t have to write any special protocols.
Asynchronous versus Synchronous
Integration Broker can do either Synchronous or Asynchronous messages. Synchronous messages are sent and the program waits for a successful response from the remote system before it will continue.

Asynchronous messages are more like the E-mail analogy – the message is sent and the program gets on with its life, assuming the message will be OK.

Most PeopleSoft EIP's are Asynchronous, and so I’ll only talk about Asynchronous messaging in this document.
Message Channels / Queues
PeopleSoft lets you group message definitions into queues. Queues can be paused or running. So if you want to keep messages with employee data from trying to go from HRMS to Financials when Financials is going to be down, you can pause the message queue. When the maintenance is over, you can set the queue to running.

They have another normally unused feature: You can change how many messages get posted to the integration broker at one time by chunking on specific combinations of fields. Message Chunking is more of a developer topic, so that’s all I’ll say about it for now.

Prior to PeopleTools 8.48, Queues were called Message Channels. I don’t believe there’s any real difference in what they are or what they do.
Service Operations
Service Operations were invented in PeopleTools 8.48. I believe the intention was to create a single place where you can define which nodes a message is valid for and what transformations need to be applied to it.
Steps in Integration Broker prior to Tools 8.48

1. PeopleCode event creates and publishes a message

2. Integration Broker looks to see if the message channel for that message is active.

3. Integration Broker creates a message instance for the message

4. Integration Broker looks to see what nodes the message is active for

5. Integration Broker creates a publication contract for each message node.

6. Integration Broker looks to see if any “relationships” exist for the source node/target node/message/version combination, and executes the transformation associated with the relationship if it exists.

7. For each publication contract, Integration Broker publishes the message (in XML format) to the integration gateway. This includes the Source and Target nodes.

8. The Integration Gateway looks for the target node in its configuration file (integrationgateway.properties), connects to the application server, and passes the message off to the target integration broker.

9. Integration broker creates a message instance for the message.

10. Integration Broker looks to see if the message is set up as an inbound message on the source node.

11. Integration Broker creates a subscription contract for the source node (if active).

12. Integration Broker looks to see if any “relationships” exist for the source node/target node/message/version combination and executes the transformation program if applicable.

13. Integration Broker inserts the message into the database based on the message definition.
Steps in Integration Broker 8.49

The process is basically the same, but the terminology has changed.

1. PeopleCode event creates and publishes a message

2. Integration Broker looks to see if the Queue for that message is active.

3. Integration Broker creates a transaction for the message

4. Integration Broker looks to see what nodes the message is active for

5. Integration Broker creates a publication contract for each message node.

6. Integration Broker looks to see if any transformations programs exist for the service operation routing or the node routing, and executes them if found.

7. For each publication contract, Integration Broker publishes the message (in XML format) to the integration gateway. This includes the Source and Target nodes.

8. The Integration Gateway looks for the target node in its configuration file (integrationgateway.properties), connects to the application server, verifies the node passwords from the source and the target environments match, and passes the message off to the target integration broker.

9. Integration broker creates a message instance for the message.

10. Integration Broker looks to see if the message is set up as an inbound message on the source node.

11. Integration Broker creates a subscription contract for the source node (if active).

12. Integration Broker looks to see if any transformation programs exist for the service operation routing or the node routing, and executes them if found.

13. Integration Broker inserts the message into the database based on the message definition.
Integration Gateway Considerations

Integration Broker got an overhaul in PeopleTools 8.48, and the older PeopleTools versions are no longer compatible with the newer PeopleTools versions.

So how can you actually make the old PeopleTools versions send and receive messages with the new PeopleTools versions? You have to make the older versions use the new Integration Gateway.

So what the does that mean? Well, you have to do is go to PeopleTools > Integration Broker > Gateways, and select the LOCAL gateway. Change the URL to be the same as the environment with latest copy of PeopleTools’ LOCAL gateway URL.
Now if you want to change any Gateway configuration, be sure to do it from the latest PeopleTools environment. Its bad luck to edit Integration Gateway configuration using a version lower than the gateway is running. Also older tools versions won’t encrypt passwords like the new ones will.

Also, if you shut down a shared Integration Gateway web server, it’s going to impact Integration Broker on all of the environments that share it. Messages should catch up whenever you bring the Integration Gateway web server back up, as long as you go to Message Monitor and resubmit the ones in error.

31/10/2015

SQR Commands
1. Example of Rpad

let $COUNTRY = 'USA'

Below example adds spaces at the end.
Rpad($COUNTRY,6,' ') ==> USA
1 2 3 4 5 6

Rpad($COUNTRY,6,z) ==> USA z z z
1 2 3 4 5 6

Rpad($COUNTRY,3,z) ==> USA
1 2 3

2. on-error command:

begin-sql on-error=Procedure-name

end-sql

The procedure will act as error handler and will have below code.
Whenever a runtime error occurs, the dynamic error message will be displayed.

begin-procedure Procedure-name
display 'Database error occurred'
display $sql-error
end-procedure ! Procedure-name

19/10/2015

How can we have DYNAMIC Prompt table for Record Fields?

Most of the times we would have faced a requirement of having Dynamic prompt table for Record Fields. Also PeopleSoft itself very much utilizes Dynamic Prompt table. How can we achieve the same in our project????

Here we go

This is accomplished by 2 ways

Using EDITTABLE fields for Prompt Table
Using Dynamic Views
1. Usage of EDITTABLE Fields

Ppl1
In this method, Prompt table property of Record Fields should be assigned with %EDITTABLE value. Actually what does it mean????

Prompt Table value for the Record Field is populated from the Record Field DERIVED.EDITTABLE value. The Record Field DERIVED.EDITTABLE should be assigned with value either in one of the Peoplecode events (Either in FieldChange or FieldEdit or RowInit events). This is simply done by

DERIVED.EDITTABLE = “PERSON_NAME”;

Note: EDITTABLE Field should be present in the SAME Page, where Record Field (In this case, The Field is nothing but EMPLID) is also referred. If the Record Field is not coming under Component Search Record Field, there is no need for placing the EDITTABLE field in the Page.

2. Usage of Dynamic Views

As we know, while creating Dynamic view, there is no need to specify the SQL. This SQL should be generated dynamically and the same should be assigned to the Record Field.

Ppl2
Say for example, if we see the above Record Field TASK_PROFILE_ID, it is assigned with dynamic prompt table view TL_TSKGRP_DVW and this view TL_TSKGRP_DVW is dynamically initialized by the following Peoplecode, which can be assigned both in FieldChange and RowInit events of the Record Field TASK_PROFILE_ID.

RECORDNAME.TASK_PROFILE_ID.SqlText = “SELECT T.TASKGROUP, T.TASK_PROFILE_ID, T.DESCR FROM PS_TL_TSKGRP_PRF_W T WHERE T.TASKGROUP = ‘” | &TSKGRP | “‘ AND T.EFFDT =(SELECT MAX(T1.EFFDT) FROM PS_TL_TSKGRP_PRF_W T1 WHERE T1.TASKGROUP = T.TASKGROUP AND T1.TASK_PROFILE_ID=T.TASK_PROFILE_ID AND T1.EFFDT

15/10/2015

05/10/2015

Understanding Temporary Tables
Because Application Engine programs run in batch mode, multiple instances of the same program often execute in parallel. When this happens, the risk of data contention and deadlocks on tables is significant. To avoid this risk, you can dedicate specific instances of temporary tables for each program run.
You can also use temporary tables to improve performance. For example, if you find that, multiple times during a run the program accesses a small subset of rows from a much larger table, you can insert the necessary rows into a temporary table as an initialization task. Then the program accesses the data residing in the smaller temporary table rather than the large application table. This technique is similar to reading the data into an array in memory, except that the data never leaves the database, which is an important consideration when the program employs a set-based processing algorithm.
Any number of programs, not just Application Engine programs, can use temporary table definitions. When you specify a temporary table on the Temp Tables tab in the Application Engine program properties, Application Engine automatically manages the assignment of temporary table instances. When Application Engine manages a dedicated temporary table instance, it controls the locking of the table before use and the unlocking of the table after use.
Parallel Processing

Parallel processing is used when considerable amounts of data must be updated or processed within a limited amount of time or a batch window. In most cases, parallel processing is more efficient in environments containing multiple CPUs and partitioned data.
To use parallel processing, partition the data between multiple concurrent runs of a program, each with its own dedicated version of a temporary table (for example, PS_MYAPPLTMP). If you have a payroll batch process, you could divide the employee data by last name. For example, employees with last names beginning with A through M are inserted into PS_MYAPPLTMP1; employees with last names beginning with N through Z are inserted into PS_MYAPPLTMP2.
To use two instances of a temporary table, you would define your program (for example, MYAPPL) to access one of two dedicated temporary tables. One run would use A through M and the other N through Z.
The Application Engine program invokes logic to pick one of the available instances. After each program instance is matched with an available temporary table instance, the %Table meta-SQL construct uses the corresponding temporary table instance. Run control parameters passed to each instance of the MYAPPL program enable it to identify which input rows belong to it, and each program instance inserts the rows from the source table into its assigned temporary table instance using %Table. The following diagram illustrates this process:
Image: Multiple program instances running against multiple temporary table instances

This is a diagram of Multiple program instances running against multiple temporary table instances.
Multiple program instances running against multiple temporary table instances
No simple switch or check box enables you to turn parallel processing on and off. To implement parallel processing, you must complete the following task. With each step, you must consider details about your specific implementation.
Define and save temporary table records in Application Designer.
You do not need to run the SQL Build process at this point.
In Application Engine, assign temporary tables to Application Engine programs, and set the instance counts dedicated for each program.
Employ the %Table meta-SQL construct so that Application Engine can resolve table references to the assigned temporary table instance dynamically at runtime.
Set the number of total and online temporary table instances on the PeopleTools Options page.
Build temporary table records in Application Designer by running the SQL Build process.

04/10/2015

PeopleSoft Technical Training new batch starting from Oct 5th. Time: 8:45AM to 10:15AM