Integration without using IOs??
The doubt is whether its really possible implement a solution without using Siebel Integration Objects or External Integration Objects.The answer is YES,its possible to implement but this requires extensive eScripting to map the data by using the EAI Data Transformation Engine,
Can a same table be used for multiple BCs?
Yes, think of an 1:M extension table wherein its possible to store different data from different BCs by just defining "Type" field.This field needs to be defaulted to the required Data Type and also need to be included in the "Search Specification" for that BC
Unchecking Force Active??
Its always better to "Uncheck" the ForceActive field property if its not being referred by the Integration Objects. Even if the Field is inactive at IO level, it would be still considered while fetching the data,this impacts the performance
UserKey not not found error while performing upsert with EAI Siebel Adapter
There are times the runtime "Deployed Integration Objects" would cause huge problem by referring at the runtime IOs instead of the updated "Repository IOs"
If the runtime IO is not deployed after the full repository then there instances where you would receive the "UserKey" problems even if there is proper data being passed as per the repository IO
Difference b/w SRF and Repository??
Many people have no clear understanding of SRF and the Repository. SRF always refers at the compiled form of the object changes ONLY.Please note its just the changes not the entire object so we still need the entire object on which the changes have been made.Hence,repository has to be moved first then on top of it the SRF is placed to reflect the object changes at the Application level.
What is the use of "Deployed IOs"??
Deployed IOs would be helpful wherein there are slight IO changes which needs to be reflected without replacing the SRF. In such instances the "Deploy IOs" would play important role
The doubt is whether its really possible implement a solution without using Siebel Integration Objects or External Integration Objects.The answer is YES,its possible to implement but this requires extensive eScripting to map the data by using the EAI Data Transformation Engine,
Can a same table be used for multiple BCs?
Yes, think of an 1:M extension table wherein its possible to store different data from different BCs by just defining "Type" field.This field needs to be defaulted to the required Data Type and also need to be included in the "Search Specification" for that BC
Unchecking Force Active??
Its always better to "Uncheck" the ForceActive field property if its not being referred by the Integration Objects. Even if the Field is inactive at IO level, it would be still considered while fetching the data,this impacts the performance
UserKey not not found error while performing upsert with EAI Siebel Adapter
There are times the runtime "Deployed Integration Objects" would cause huge problem by referring at the runtime IOs instead of the updated "Repository IOs"
If the runtime IO is not deployed after the full repository then there instances where you would receive the "UserKey" problems even if there is proper data being passed as per the repository IO
Difference b/w SRF and Repository??
Many people have no clear understanding of SRF and the Repository. SRF always refers at the compiled form of the object changes ONLY.Please note its just the changes not the entire object so we still need the entire object on which the changes have been made.Hence,repository has to be moved first then on top of it the SRF is placed to reflect the object changes at the Application level.
What is the use of "Deployed IOs"??
Deployed IOs would be helpful wherein there are slight IO changes which needs to be reflected without replacing the SRF. In such instances the "Deploy IOs" would play important role
No comments:
Post a Comment