Running Jobs in Global company

[Former Member]

hi

whats the better way to run the jobs at various times ? as a job running in US nighttime, can hamper the users in Asia. Especially, Realignment, if the users across the globe using the same MPOS, as it will fail if other users accessing the pl books.

So i am thinking on the best way to handle all this ? any good suggestions pls ?

thx

venkat

[Former Member]

closing the thread.

[Former Member]

Hi

Thx for all of you for the help.

Can anyone give me some idea how to write a z program to kick out the users from the PA ?

Like the main coding part ?

It looks this is only the solution we have in a global situation for running the jobs.

thx

venkat

[Former Member]

Hi Venkat,

Yes..Your have valid questions and concern.

Thanks for good input from Somnath

This is quite possible if you share PA and run realignment jobs. Active users in planning book will fail the job.

You need to develop Z program (Macro can be used for the same whereby Z program can be called) to block regional planning area where you run realignment based on regional time zone.

I have seen many similar questions in this forum asking about similar issue.

The answer is same as suggested above.

One more possibility but we have not yet tried....Just to be sure users that no active users available in PA (Planning book ) before job starts is to add one step in realignment program to kick off users from PA.

This may be useful if you have one single PA shared by global users.

Hope it helps..

Cheers!

Ravi

[Former Member]

hi

thx for your response. I am only talking about DP, which has 4 PAs and same MPOS for 2 business groups.

Now, these 4 PAs are used by all the regions based on the business group. Ofcourse, CVCs will be different.

Main worry is how to manage the Realignment execution. To run that, i think no one should be in edit mode irrespective of CVCs.

So i am looking fwd for any solutions implemented in global scenarios.

thx

venkat

[Former Member]

Hi Venkat,

We also faced a similar problem. Although we do not use realignment, we had issues with the users in a particular regionin the planning books (affecting the planning area) when the job was running for the other regions.

To partially overcome this issue, we have developed a Z program which locks and unlocks the planning area. During this window, we run those jobs which affect (saving of data) the planning area.

I am not too sure if such a program may be built for locking the MPOS when yor realignment job runs.

Hope you find this useful.

Regards

Sandeep

[somnath_manna]

Running jobs in a Global Company

The design of jobs will depend on the application.

Let's take DP - if you have a single Planning Area / MPOS then you are not left with much choice.

This is why many global companies would go for separate planning area / MPOS by geogrpahical region like Americas, Europe & Africa, West / Mid-Asia and Asia-Pac. Note all the MPOS share same characteristics and the keyfigures in the Planning Areas remain the same.

With multiple MPOS you also get benefit in terms of performance as number of CVCs will reduce. Likewise Data Extraction from Planning Area to Backup Cubes and the other way round (load data from Cubes) can also be faster and jobs run at different times for different geogrpahies.

However for SNP there is one Planning Area but transaction data is stored as OrderSeries in liveCache. You can always run Planning Run (Heuristic) jobs for a given Product-Location selection which can be based on some Geographical Regions.

The same goes for PPDS as well.

However caution needs to be taken when you are running jobs in one region which have an impact on another region e.g. North America's Constrained Demand Plan is released to Global SNP Planning Area and the Supply Plan is carried out in Asia-Pac as the Supplying locations.

Hope this helps.

somnath

[Former Member]

Hi Venkat,

I guess the best way to handle this is maintaining access control via Selection Profiles. provided that the users are accessing the different DATA as per there region.

regards

Kumar