(6 votes, average: 4.67 out of 5)
Loading ...I came to know about really weird behavior of Inactive Flag (in Siebel tools) after Amol (a colleague) pointed it to me. I was not ready to believe him and had to try for myself (in the process I lost a bet of One Trillion $ 
to him and promised him to gave a written apology )
Scenario:
- Create a business service in Siebel tools.
- Compile this business service it in SRF.
- Run that business service
Expected Behavior: It should run successfully
Actual Behavior: It runs successfully - Inactive the business service by clicking on Inactive Flag.
- Compile it again in SRF
- Run that business service
Expected Behavior: It should give error that BS does not exists
Actual Behavior: It still runs successfully.
Observation:
- If you do a compile an object (incremental compile) after making that object inactive Siebel doesn’t delete the object definition from SRF and that object still works as expected.
- If you make changes to inactive object definition those are not picked up. Last active object definition is picked up.
- Even if you rename the object after making it inactive or compile the project it doesn’t makes that object inactive.
- This only happens for parent objects such as Business Component, Business Objects or Business Service. If you make inactivate BC fields and you do an incremental compile it works as expected
- Only after full compile an inactive object definition is removed from SRF.
Probable Reason:
Rahul (another colleague) pointed out that may be Siebel Compile process just skips the object that are marked as inactive.
So, when an object is marked as inactive and we do an incremental compile Siebel does nothing (it means it skips the compile of this object and SRF remains as it is) that is why you still get the old active object definition.
But when we do a full compile all the objects definitions are compiled from scratch and inactive objects are skipped hence you get an error. I tried this with Business Service and Business Component objects and both worked in same way. I am not sure if this valid for all the objects or there are exceptions.
If anybody out there can put some more light on it or explain it better (I still cannot believe this happens) it will be really great.
P.S: Amol I do apologise for doubting you .
Authors bio is coming up shortly.
Loading ...
Very informative…
Thanks for sharing!!
Bharat
>> If anybody out there can put some more light on it or explain it better (I still cannot believe this happens) it will be really great.
I simply can’t see what is so weird about this case. Even more, why someone couldn’t believe in this
When Siebel compiles an object incrementally, it adds it’s definition at the end of SRF file. But it replaces this additional SRF object if you incrementally compile it later. So, there are never more than 2 compiled definitions of the same object in one SRF file.
When reading the SRF file, Siebel uses the incrementally compiled definition if it exists or the first one.
As for the mentioned case, Siebel skips all inactive objects during compilation process. It executes such a query if you like: [Inactive] = ‘N’
So, if you inactive a top-level definition (i.e. BC) then this whole definition is skipped and SRF is left intact. But if you inactive a field, than this change is instanly reflected in SRF since a TOP-LEVEL definition (BC in our case) is replaced in SRF, including its child nodes (Fields, Joins, MVLs etc.)
Quite obvious as I’ve said
There are few things that I don’t think are obvious here.
1. When Siebel compiles an object incrementally, it adds it’s definition at the end of SRF file. But it replaces this additional SRF object if you incrementally compile it later.
Doubt: why it creats an additional defination of an object why just not replace the existing defination as it can replace it once we try to compile again.
2. So, if you inactive a top-level definition (i.e. BC) then this whole definition is skipped and SRF is left intact.
Doubt:
Obvious thing here is that when we compile the object its definations are added. It is not very obvious that you will compile an object and it will skip it and do nothing.
shouldn’t there by any indication of that. I mean may be just warning that nothing has been compiled.
Very informative Neel. I was also under assumption that if you inactive the object and do the incremental compile, it should get reflected at the same time.
Cheers,
Jimit
2Neel
>> Doubt: why it creats an additional defination of an object why just not replace the existing defination as it can replace it once we try to compile again.
SRF is just a binary file. It is much easier to append a definition rather than search through the whole file and replace it. Imagine what time a compilation would take if EACH object was looked through first.
>> Obvious thing here is that when we compile the object its definations are added. It is not very obvious that you will compile an object and it will skip it and do nothing.
Again, browsing through a binary file is a very time and resource consuming operation. So it only natural that Siebel doesn’t look for the definition to erase it from SRF when you checked Inactive.
To spread more light on the situation I suggest you should take a closer look at the size of SRF file. When you incrementally compile a definition SRF is increased in size a bit. When you later recompile the SAME definition the size is left the same. When you inactive a definition and compile it, the size – who would have thought – is still the same
I remember problem I had with this issue. I have been fiddling with some user properties on BC, then I realized I will deactivate them and moved it to script. I compiled BC, but they were still active! I thought Active flag was somehow ignored, so I had to remove them. Now I see why that happened.
Thank you neel, keep it up.
Viktor, when you compile a root definition, like BC, a new structure is always created in SRF, reflecting the current state of its descendants (including user props in this case).
That is why if you inactive any user property and recompile the BC this property won’t appear in SRF.
This is how it works in 7.8 and 8.0 at least and I suggest you reconduct your experiment once more (i.e. create BC Read Only Field and then inactivate it). It disappeared from the SRF in my case.
Let’s assume that what you are saying is correct. When we do an incremental compile it doesn’t searches the whole file for the defination of the object it just appends a defination.
Doubt: Why does it replace the defination when we recompile that object after making change. For example when I do an incremental compile for first time it creates a new defination and appends it in end of file. Now I do an incremental compile of the BC again after making the change. It replaces the same object defination.
To do that it has to search for that object right???
Why not do it first time itself.
Logical question. My assumption was based on the fact that the size of the SRF doesn’t change when you recompile the same object.
If there is a special delimiter in SRF which separates incremental objects from the initial ones then browsing through incremental area is faster than through the whole file.
Although I tend to believe now that there is no such separation and every incrementally compiled object is just appended to the end of the file.
The reason of the fact that SRF size is not increased may as well be that Siebel allocates SRF data in blocks, which can hold several definitions.
It’s a lyrical digression, however, since it doesn’t change the way Siebel handles inactive definitions
Vertex,
Jason at http://siebelunleashed.com/understanding-srf-file/ commented same behaviour. I am not 100% sure that this happens to every one BC user property or everytime, but it is something to be aware of, because it can happen after incremental compile.