Searching adapters

Recently a table was updated to have two new columns. All of the adapter services that access the table now need to be updated to select as well as update the new columns. Multiple adapter services were created for the table to query by different columns. Multiple were created so that parameter markers could be used. This is per standards. As the adapters folder has close to 50 adapter services for this project due to many different tables being accessed using a variety of columns as well as in different flow services SQL is being hand coded based off of the request it would take a very long time to look at all of the adapter services and flow services manually to find where the table is being accessed. It is the most accessed table we use. All of that to get to my question: Is there a way to search against the adapter services for a specific table name? I can search the flows using any search tool i.e. egrep but that doesn’t help in searching adapter services. In the package structure in IS, if I look at the “node.ndf” it has all of the column names but not the table name so a search does no good. How can I search a package for a specific string and it search the adapters as well? I would like to be able to "find in value "
Thanks!

I don’t think you can do that. The JDBC adpater services are saved in xml file (just like normal flow services), but the query are save as a based64-encoded object, embedded in the xml.
you may want to start a new coding habit of adding enough comment for the service, so you can search in the future.
HTH,
Tong

An approach that we implemented was a custom service that traversed adapter services and retrieved adapter service information. Then decode the base64 encoded properties and search on the string. It’s a bit involved but there are various services (take a look in WmART) that you can leverage to traverse adapater services and then examine them programmatically. How complex the service you write depends on how flexible/robust you want it to be.

One note of caution: Do not modify any data in any of the returned structures related to the adapter service (e.g. don’t do an toUpper or anything like that which is common when comparing/searching). Doing so will modify the in-memory representation on the IS box which will be returned to anyone that might viewing/editing the service–if they edit and safe, the modification will be saved permanently to disk and may result in service failure (character case is important in some SQL statements).

Hope this helps.

Thanks for the replies. Yes that is very helpful. I was thrown off by the SQL being base64 encoded. I wasn’t aware of it but now I can do as you suggested and create a service to decode it for me.
Thanks!