Can a batch job be used to create a package and apply approvals?

[Anon Anon]

I am exploring all possibilities for having out change system (Service Now) automatically generate Packages in ENDEVOR, and apply approvals,  Process I am thinking about is someone creates the entry in Service Now,  the endeavor package job gets build, after the last approval is given by the change team a second process is kicked off and the approval is applied and package executes

 

We use ESP and ENDEVOR. One thought occurred to me is if we could generate batch jobs to handle all this? Can this be done?   I could see a job to take parameters from Service Now and create the job in a secure locked down library, have a dataset trigger to trip the job via ESP.

 

I have read about companies that handle this process for people and user 3rd party processes or sell their services, I wanted to explore with the ENDEVOR folks this question before I take a step further.

 

I understand this may be an impractical solution, seems straight forward to me, but others may have tried and ran into road blocks.

 

Thanks!

[roger.howard]

We have an API program in-house that will ADD the element to an ENDEVOR stage, Create, cast, approve, and execute the package.  The API program was written for a specific situation in our environment.  The program must be executed under a specific userid, as we have ESI in our shop and most of the security is handled by Top Secret.  I don't know the specifics of your situation, but yes, it is possible to do what you want with an API.  I'm not sure that you could do it entirely with Batch Admin commands. 

[Efren Yanez]

Hi bgilbert1.1

 

I´m  sure you can do many things using a batch job, only you have to build all the necessary for that job to run.  For example, I would like that you take a look to this example "job" used  (see attached file "JobApprovePkg.txt")

 

- The rexx "runpkm00"  in step "PASO0001" is used to generate the due SCL according the action (APPROVE PACKAGE, DENY PACKAGE, EXECUTE PACKAGE).This rexx only buils the "scl"  like you known on DSN=&&TEMPSCL
- The rexx "RUNPKR01"  in step "PASO0002" is used to generate a successfuly notification of the previous action (steps PASO0001 and ENBP1000)
- The rexx "RUNPKR01"  in step "PASO0003" is used to generate a not successfuly notification of the previous action (steps PASO0001 and ENBP1000)

 

I hope this help

 

Efren

Attachment(s)

JobApprovePkg.txt.zip   863 B 1 version

[Anon Anon]

We have done this in batch for quite a while. Creating the package is easy, identifying the required contents can be more difficult. We were dealing with single elements, much easier. However we had automatically built larger packages as well.

 

Multiple approvals can also be handled in batch, we had set up a very specific system/type where only one approval was required and very few users could access it at all.

[Eoin OCleirigh]

Great topic!  I love it, and all the responses!

 

Two thoughts spring to mind - first of all if you are creating the package and the approval from an external source, you can probably simplify it to JUST creating the package because you could set up the source (service Now (or ESP) in your case) as a quorum of 1 approver - then creating the package from your secure system will automatically approve it.  Of course you have to make sure that your job submit process from ESP is secure, but then setup should be one off.  Of course you could add multiple approvers, or external approvers and perform the approvals the old fashioned way too.

 

However, the one reason I'd consider some of the 'external solutions' for integration is whether you want the process to be bi-directional.  Normally this is the value-add of a more robust solution, so while it might seem sufficient to kick off the package create/approve/execute process from ESP - where should message go when something fails?  Do you need logging back to ESP when a package is successfully executed, how about additional process that depend on the package state, like kicking off a ship, once a package has executed, or denying it once it's been committed?  I'm not saying you couldn't add those bits to your process too, but at some point it becomes more complex than you might like to manage.  Ideally you should capture failing states (like package already exists) before kicking off a batch job - but this is just the start.