cancel
Showing results for 
Search instead for 
Did you mean: 

ESR & ID Transports

Ryan-Crosby
Active Contributor
0 Kudos

Hello,

I do not have a technical problem but merely a question regarding how transports are handled within other organizations for ESR & ID objects?  It has been a finding within our organization that developers should not handle import of ESR & ID objects.  Is this the case in other organizations as well and if so, who handles the PI transports within your organization?

Regards,

Ryan Crosby

Accepted Solutions (1)

Accepted Solutions (1)

former_member184720
Active Contributor
0 Kudos

It depends but from my experience, i see majority of customer's let the basis folks take care of import process.

In such cases,

we have had special user ID's with the required authorization opened for certain duration to handle configuration changes.

or

Provide configuration changes such as connection details/parameter's in an excel so that they can update after the import.

However i did notice few customer's where a developer takes care of everything.

Ryan-Crosby
Active Contributor
0 Kudos

Hi Hareesh,

Even in the newer single stack Java platforms where to my knowledge you need to be using NWDS to activate the iFlow content?

Regards,

Ryan Crosby

former_member184720
Active Contributor
0 Kudos

Yes.. That's true..

Once we import iflow, we deploy them in the target environment using NWDS.

nabendu_sen
Active Contributor
0 Kudos

Hi Ryan,

You are correct. Check "Activate the iFlow" section in the below document:

How To Use the iFlow Eclipse Tool with the Integration Directory

Regards,

Nabendu.

Ryan-Crosby
Active Contributor
0 Kudos

Hi Nabendu,

I'm not really asking how to execute these actions but more to understand which persons(s) take on this responsibility in production environments within different organizations.  It has been suggested in our organization that developers should not perform this action but I find it troubling to relinquish this activity to a person that may not be trained and understand what they are viewing in NWDS.


Regards,

Ryan Crosby

Former Member
0 Kudos

For ESR we have a transport workflow, so the PI team (who can also be developers) are creating the transport using CTS+. Before the workflow allows it to go to production an approver must sign into Solution Manager to approve the final step of the workflow. Then the transport is moved automatically. For ID Config changes it is handled by the Basis team.

nabendu_sen
Active Contributor
0 Kudos

Ryan, got your point.

In my current project, we have CTS+, so we create Requests with CTS Organizer. Basis team actually performs the movement of the objects. Activation of ID done by Developer.

In my previous project, we had CE BPM 7.2 and we were using NWDI. So the developer actually deploying the objects into Production. PI had separate object movements through CTS (Solman - SE10) process.

Regards,

Nabendu.

Ryan-Crosby
Active Contributor
0 Kudos

Hi Nabendu,

I should have been more specific in my question above, I was really leaning towards the activation piece which you have answered in your last post.

Regards,

Ryan Crosby

Ryan-Crosby
Active Contributor
0 Kudos

Hi Aaron,

I should have been more specific regarding the answer I was seeking.  It was more around the activation steps involved in ID.  Do you mean that BASIS also performs all of the activation in the system?

Regards,

Ryan Crosby

Former Member
0 Kudos

Yes, Basis is activating all config changes in ID. ESB activation happens immediate automatically in our workflow.

JaySchwendemann
Active Contributor
0 Kudos

In our organization (where we use NWDS for ID part) basis does transport via CTS+ and developer do activate those parts, just like Nabendu.

I am with you about the uncertainty when having basis to activate (hence deploy) ID stuff they not really know about.

I think from a separation of power point of view it should suffice that you as developer may request a transport and basis does this transport. Activation (deployment) of ID stuff is something that is very specific to PI. If you compare to say normal ABAP transports in ERP system, there's no such thing as separate deployment. After transport your code changes are instantly live.

However, I should add that we have a non SAP based workflow process in place where we need to have transports "approved" by a requester that is not the same person as a developer.

So for PI (ID objects) the normal transport process looks like this:

Department requests some interface --> Developer creates / changes interface and creates transport --> department tests interface and approves transport --> devoloper asks basis to transport --> basis carries out transport --> developer activates transport --> live.

HTH

Cheers

Jens

Former Member
0 Kudos

Hi Ryan,

Regarding the topic of ID object activation:

At my previous employer we defined a Solman/CTS+ based procedure where the basis team handled the imports. On the ID part we did not work with iFlows back then, but in general we had auto activation of changelists in place.

This means that we did not include new communication components and communication channels in transports - because CCs cannot be auto activated due to being imported empty. Instead they were exported as files from the dev system (by the developer) and attached to the corresponding change document on Solman together with a description about how the CCs should be filled.

So before an import to the production system took place, the basis team performed all kind of 'manual customizing' - which on PI included the import of the archives, filling of the CCs (according to the description that the developer provided) and activation of these manual imports. Afterwards the transports were released and changelists were activated automatically.

This worked quite well in general, but of course it took quite some manual effort.

Therefore I would have liked to built a directory API based tool to get rid off the descriptions for the CCs. So instead of the file export and creation of a description, I would just attach a script which can be executed in order to create and fill the CCs.

engswee
Active Contributor
0 Kudos

Hi Ryan

Interesting discussion you started here

In most of the organizations I've worked with, the final activation part on ID objects in Production was done by developers, whether the transport was via File or CTS+. The only part that Basis folks came in was on the moving of .tpz file from source to target (back in the days before client based file import was available) or executing the import on ID (but not activation).

Like most of the rest here, I would be also hesitant to let the final configuration and activation be performed by a Basis consultant unless they have been trained. One possible alternative for this approach would be to provide developer a read only access to ID to verify the completed configuration.

Rgds

Eng Swee

Ryan-Crosby
Active Contributor
0 Kudos

Hi Eng Swee,

Yes, I was curious to understand how other organizations are handling the transport and activation of content.  The finding was that a 'developer' should not perform this action because it is a risk to the system.  My contention however is that it is not merely a 'developer' that could perform some unwanted action in the system - whether intentional or not.  A job title for instance only outlines my role but does not set boundaries for what skills I might have.  An untrained individual, a former developer turned BASIS or simply a BASIS person with development knowledge and keen insight into the system could all cause some issue.

If I take into account some of the possibilities I think the most likely occurrence would be that an untrained individual would put information into the system that would cause some business process to fail.  For that reason I would say keep the activation of content with the folks that built the scenarios from the start and understand the full end to end flow of the integration.

Regards,

Ryan Crosby

Former Member
0 Kudos

Hi Ryan,

From a logical point of view, I fully aggree - the developer would be the person with the most experience to handle the imports to production. On the other hand I guess why most companies handle it differently is the whole topic of 'separation of duties'.

The requirement in my former company was that the descriptions ("how to fill the CCs") had to be so precise, that the cleaning staff could handle it. The basis team also 'trained' the described procedure when the imports to QA were done as kind of final rehearsal and quality control for the built of production. Of course we used templates for different kind of CC descriptions, but it was still a lot of monkey work. Therefore my preference here would be to automate using the API in similar future situations.

Maybe to bring one more thought into the discussion:

Sometimes I wonder if we should not treat ESR and ID in a different kind of way. For some tasks it might make sense to open up the ID part (also on production) to be changed by the developers. I guess the clearest example is for CCs - when a connected system changes (e.g. a hostname), then we should be able to react to it quickly without a huge administrative burdon. But I would go one step further and also allow to change _existing_ integrated configurations (and the corresponding objects on the dual stack) and to add new business components / CCs. For example if you want to roll out new partners on existing interfaces (and mappings) it does not make much sense to me to restrict this. I would compare it to adding some table entries (like condition records) in ABAP which is usually open on prod.

The ESR on the other hand should be closed, as this is for me where we really generate 'new' content. Therefore it makes sense to me have a strong governance procedure in place in this area.

Ryan-Crosby
Active Contributor
0 Kudos

Hi Christian,

I completely agree with respect to the segregation of duties for the ESR transports because those can contain executable code for all the mapping logic.  I do like your analogy for the ID with it being likened to configuration entries in the ABAP side of things - I usually refer to it as the metadata which describes particular details about the integration.

The trouble I see with passing on information to another party for ID content is then the developer becomes a relay for pertinent information related to the integration.  This type of scenario makes me think of the game telephone where everyone passes on what they hear from the person on one side and then relays it to the person next to them and you see what message comes out at the end.  It doesn't take very long for the message to become garbled such that it is not a reflection of the original message.  Taking away access to change CCs for instance also doesn't allow us to respond to potential production issues or make changes when a partner has a hostname change like you have mentioned.

Regards,

Ryan Crosby

engswee
Active Contributor
0 Kudos

Hi Ryan


For that reason I would say keep the activation of content with the folks that built the scenarios from the start and understand the full end to end flow of the integration.

I agree with this. The folks that built the content would most often understand it best and be the most "qualified" to complete the activation.


The finding was that a 'developer' should not perform this action because it is a risk to the system.  My contention however is that it is not merely a 'developer' that could perform some unwanted action in the system - whether intentional or not.

IMHO, it will be a bit narrow-minded of an organization if it considers developers to be a risk to the system. So when they require a program to be developed and ready for UAT, the developer is an asset, but when it's time to promote it to production, suddenly the developer is a risk?? Like you said, there are more ways/roles than one that could introduce issues into the system. Not just in PI, but even an ABAP program could be written with an easter egg feature that could not be unveiled during UAT. Only the most strigent QA review process that pores over each line of code (or mapping logic) might unveil it, but which organization would be willing to implement such a time-consuming and tedious process?

Rgds

Eng Swee

Answers (3)

Answers (3)

robert_warde4
Active Participant
0 Kudos

Hi Ryan

We use CTS+ for the physical transport and HP-PPM for the Development Lifecycle Management

  • Developers create the transports
  • The central Integration Team (My team) QA and release the transports
  • A central Release Team perform the transport
  • Developer performs post transport configuration

And so on...

The HP-PPM system managed the whole development process. For example

  • Initiation
  • Approval of Functional Requirements
  • Approval of Technical Design
  • Development
  • Code Review
  • Transport Request
  • Transport Approval
  • etc...etc..

Our business consulting team (functional experts) approve all transport requests. My team performs the Code Reviews and Transport Approvals. Its all automated and everyone involved is sent an email as the status of the request changes. Works well.

iaki_vila
Active Contributor
0 Kudos

Hi all,

Definitely you are lucky guys

My organization usually works for public administration in Spain. The flow transportation goes in this way (in the worst case):

ESR or ID transport.

1. The transport to quality, we  can do it the developers.

2. When the scenario is tested in quality, i have to send a mail to my project responsible, with technical and business information, remind the necessity of the new/change scenario and so on

3. My responsible send a email to client responsible.

4. If it is possible a technical client user tests the change. If all is right he confirms the change.

5. Client responsible send a email to my responsible.

6. My responsible resend me this email. Then i need to send the files/paths and a document that explains how to do it the transport (normally, i can reference a template).

7. My responsible send an email to client responsible.

8. Client basis team makes the transport file according my document.

9. Basis team send an email to their responsible project and they communicate with my company project responsible.

10. My responsible tell me that the file is available and i do the import.

To change an ID object, i need to do a document in quality explaining how to configure in Production, only client technicals can modify production objects.

The red tape never dies...

Regards.

engswee
Active Contributor
0 Kudos

Inaki, one word ... "Wow!"

Ryan-Crosby
Active Contributor
0 Kudos

Wow is right, I would have to start playing golf more often to practice my patience if I had to go through those steps every time.

iaki_vila
Active Contributor
0 Kudos

Hi Ryan

If you can't avoid transport for determinated user this Michal¡s blog can be helpful for you https://scn.sap.com/people/michal.krawczyk2/blog/2012/01/15/michals-pi-tips-disabling-file-transport...

Also, you can try removing this role SAP_XI_CONTENT_ORGANIZER_J2EE

Regards,