Question

Pega Deployment Manager - 8.2 - Stops with : Http status code of call back:301

Please help me with the issue I am facing with Pega Deployment Manager:

I am doing a POC with Pega Deployment Manager (Pega 8.2 and 4.4 deployment manager). For POC purpose I use the same Pega instance for Dev, QA and Stage with HTTP protocol only. I did complete the following (order may be typed differently here):

  1. Created a pipeline with jFrog repo.
  2. Created RMURL DSS with http://localhost:<port>/prweb/PRRestService with ruleset as Pega-DevOps-Foundation
  3. Ensured all Auth Profiles are having the correct password (DMAppAdmin, DMReleaseAdmin, jFrogAuth) and enabled the users after changing the password.
  4. Since it is HTTP only, cleared the check box - "Require TL/SSL ... " in cicd and api service packages
  5. Ran the Diagnose pipeline (attached the screen shot)
  6. Clicked Start deployment
  7. I verified from the folders that the product zip file is created and copied to jFrog repository also.
  8. However the status of the job in Deployment manager shows as ONGOING with no further execution of the stages in the pipeline
  9. The Pega log shows the error as below:

2019-06-26 01:43:50,812 [ PegaRULES-Batch-4] [ STANDARD] [ ] [gaDevOpsFoundation:4] (apper.Pega_Int_Pipeline.Action) INFO DMAppAdmin - Task execution completed for task : publish
Posting status to release manager system. Status object:
{
"pxObjClass":"Pega-Int-Pipeline"
,"pyAccessGroup":"AISample:Administrators"
,"pyApplicationName":"OnBoarding"
,"pyApplicationVersion":"01.01.01"
,"pyBuildArtifactName":"OnBoarding-OnBoarding_010101_18.zip"
,"pyCallBackURL":"http://demos.research.com/prweb/PRRestService/cicd/v1/task/publish/status?FlowName=pzPublishRAPCore&FlowActionName=pzPauseTask"
,"pyDoPackage":"true"
,"pyFilePath":"devops/dev/OnBoarding/01.01.01/OnBoarding-OnBoarding_010101_18/OnBoarding-OnBoarding_010101_18.zip"
,"pyID":"PEGA-PIPELINE-CD ON-18"
,"pyPipelineName":"OnBoarding"
,"pyProductName":"AISample"
,"pyProductVersion":"20180807.083250"
,"pyRepositoryName":"JFrogRepo"
,"pyStatusValue":"SUCCESS"
,"pySystemNodeID":"31b730a953128c5792668c0f384f20e3"
,"pyBuildArtifact":{
"pxObjClass":"Data-Artifact"
,"pySize":"1638982.0"
,"pyTargetLocation":"devops/dev/OnBoarding/01.01.01/OnBoarding-OnBoarding_010101_18/OnBoarding-OnBoarding_010101_18.zip"
}
}

2019-06-26 01:43:52,838 [ PegaRULES-Batch-4] [ STANDARD] [ ] [gaDevOpsFoundation:4] (tatus.Pega_Int_Pipeline.Action) INFO DMAppAdmin - Task execution status published by doing call back for task name:publish
Http status code of call back:301
Status message of call back: WARN: HTTP Response code indicated redirectionthe HTTP response code of 301 indicated a server redirection. Redirection is not enabled for this Connector.

Comments

Keep up to date on this post and subscribe to comments

June 28, 2019 - 2:04am

Do anyone know the root cause of the failure?

June 28, 2019 - 5:26am

If there is an option to set the value of pyCallBackURL to http://localhost:port then it would have solved the issue. But unfortunately the Data Transform setting the value is "Final"

July 1, 2019 - 11:14am

Hello, 

It is impossible to know why you are being redirected (which is what that HTTP 301 error code means) with that information. My guess is that  that domain "http://demos.research.com" is redirecting you for some reason.

See if you can attach other logs and check what is going on with that error that you can see in the diagnostic tools.

July 3, 2019 - 6:09am
Response to DiegoAlonso

Yes, I checked with my IT team and looks like the host / public network is configured to redirect to our private network. Hence the error. So for now, there is no way to fix this unless as I mentioned if pyCallbackURL takes the URL from the Pipeline settings given by us.

Pega
July 4, 2019 - 5:38am
Response to BalajiD0

Hi Balaji, could you please answer following questions:

Is the orchestrator system same as the dev , prod and staging system?

And from where did you get the Pega logs , orchestrator system or from the candidate system if they are different systems?

Thanks.

payal

July 9, 2019 - 3:26am
Response to basup

Yes, the orchestrator system is same as dev, staging and prod as I mentioned above.

And, when I try from other instance where there was no reverse proxy then it works. So my only thought is if the pyCallbackURL is formed based on the URL given in the settings in deployment manager (as we give http://localhost), then it will work well even in reverse proxy. Thanks.