Suggestions - PI Integratipn Directory usage

[Former Member]

Hello Everyone,

This would be technically PI specific.

After several implementation and handling a huge support structure at present, very frequent problem we face are the changing laws of various countries due to which some or other communication information has to be edited (if not a complete new development). I have seen several landscapes where the systems involved are part of many Configuration Scenarios in Integration Directory. Changing communication details of one system (e.g. the IP address in case an IP is mapped to some external IP or simply the file folder path or some webservice URL or there could be hundreds of such cases) often creates a problem in Production where a lot of ID objects have to be manually edited as the transports in ID could not be the perfect solution.

Could there be a functionality in ID, say a "Variable" (may be with some specific naming convention) which could be defined to store any ID object related data. It could be any string, say a communication channel detail, or a frequently changing xpath condition. This will ease the post transport activities to some atleast some extent. Also, the sudden change of details in Production Environment would be much convenient to handle. It could be a simple name value pair but could prove out to be reusable.

May be I could not see the dark side of it. Kindly come up with your ideas about relevance of this option.

I hope this is the right place to post this and I will get some response.

Best Regards,

Prateek

[aashish_sinha]

Hi Prateek,

I don't know if i understand it correctly or no, but it is not possible till PI 7.0. Now with new release of PI 7.1 there are something called parameterize mappings. Advantage of using parameterize mapping is to reuse of mappings in multiple Interface Determinations with varying parameterizations. We can also set channels for lookups at configuration time.

We all need to do is, in Message mapping, define parameters depending upon the Simple type or adapter specific (if adapter specific we can provide JDBC, RFC, SOAP etc.). Now in Operations mappings we need to create parameter for and in we need to bind these parameters in Operations mappings using Binding link, which is just besides the MApping Type in OM. After binding these Parameters we can use this in Interface determinations and in channels. We can also use these parameters in Inegration Processes.

In interface Determination, we have to add relevent Operations mappings and assign constants or channels to our parameters.

Waiting for your input if you were really looking for this.

Regards

Aashish Sinha

[prateek]

Aashish, thanks for showing interest here.

The point raised was more about the ID objects. I understand the parameterized mapping and its capabilities. Its useful when we talk about the modifications in Design objects and not the configuration objects. e.g. in lookups instead of hardcoding some value, we can have parameters and configure it in ID. The issue I raised is more about ID related changes like IP or URL of some communication channel.

In my opinion, parameterized mapping won't help in that case.

Regards,

Prateek

[former_member181962]

Hi Prateek,

Its definitely a nice feature to have.

May be SAP is preserving this type of a feature to be unleashed in next version.

After all if all the good features are there in the current version, there would be no scope for the next version...:D

On a serious note, I would liike to see someone playing the devil's advocate here, negating your thought process..

Regards,

Ravi Kanth Talagana

[prateek]

I would liike to see someone playing the devil's advocate here, negating your thought process..

Thats one of the main reason I raised it here. As I said in the first post, the dark side has to be unleashed before thinking about such options.

Regards,

Prateek

[Former Member]

I agree with you completely, once you have a sizeable base of interfaces (i.e. thousands), the channel details can become a nightmarish thing to maintain.

Appart from designing/changing an adapter template in IR and later applying the template in ID, there is not much you can do to make "massive" changes to objects in ID.

Also you could probably build an application that uses the ID API to make the changes for you in the pertinent places.

I think the adapter details should be "read" from the corresponding technical system in the SLD by default, since the cchanels are created under business systems already, it should not be so difficult to have some BS/TS attributes be inherited to them.

-Sam.

[prateek]

The usage of "Variable" as I said earlier could be some functionality provided in ID directly or it could be a small hosted application which could use the ID API internally.

Addition of communication details in SLD however doesn't seems to be much fruitful to me. The frequent changing requirements are handled by Developers which usually doesn't have SLD authorization. Dragging an SLD Administrator for each change couldn't be an optimal case.

Sticking to the "Variable" related suggestions, what I grab out of your reply would be some application exploiting ID API. Looking for more comments.

Best regards,

Prateek

[JoelTrinidade]

Hi Prateek,

Write to SAP , if they incorporate your suggestions in there architecture ... you could live off on royalty.

Regards

joel

[prateek]

Joel,

The intention of posting this to get response from the community about the relevance of this requirement. I am not sure how to communicate this directly to SAP. In any case, the most important thing is to understand both positive and negative aspects about it.

Regards,

Prateek

[JoelTrinidade]

Prateek a Million dollar thought.

the most important thing is to understand both positive and negative aspects about it.

Regards

joel

[prateek]

More thoughts!!

[Former Member]

Prateek,

Have you considered using Adapter-Secific Message Attributes? You could, for instance, set the url for an HTTP communication channel in a ASMA. Especially if you combine this with a value mapping, this could make changing the host much easier. Just change the values in the value mapping (ID).

Unfortunately, this procedure won't work for all parameters in all adapters. For instance, the hostname for an FTP adapter cannot be set in ASMA.

Kind regards,

Koen

[prateek]

I agree about the capabilities of adapter specific attributes. However, as you said, they do not serve the complete purpose. As I mentioned earlier, if there is a sudden change required in some channel parameter like username, hostname, RFC destination name etc in production, then we have no choice but to perform all the changes manually.

The change I mentioned doesn't seem to be that big a change for SAP. More comments please.

Thanks,

Prateek

[Former Member]

Hi Prateek,

Nice point raised , Yes it's very cubersome process to change credentials on every adapter level when there is a change.

We have currently faced the same issue where in we are bound to changes in the credentials due to policy rule and some time change in server.Due to this since it needs manual intervention which is bound to error some times.

Now am not giving solution but well this kind of option , like selecting Username and password from a drop down list.For this we have to before decalre all our Username and password assign to Name (TestDB) this testDB should hold set of Sender JDBC Adapter as group , so any chanes in TestDB credentails wud effect all Adapters in the group.

Hope this wud be handly in large landscape and bound to less errors.

rgds

srini