I work with the Siebel Web protocol all the time and i prefer to use
the native correlation rules over the ones provided by Siebel. Sure
the added rules help you grab more stuff but the correlations are not
always on target either. Also, you end up with so many possible
parameters to choose from it becomes confusing. But thats just me and
this opinion is highly subjective. As a matter of fact, my partner has
the Siebel rules installed and swears by them so yeah... you can try
them and see for yourself :)
To answer a little on your questions:
rowids: The single most important part of a record. You can use it to
retrieve a given record but you will also need it to perform actions
like "delete", "drilldown", "select", etc. You will also need it as a
"reference" when you want to navigate through a record's sub tabs.
This is vulgarized but maybe it'll help shed some light:
SWERowId = rowid to perform the action/method on
SWERowIds = record's parent rowid
SWEACn & SWC:
These gave me a lot of trouble at first but for two different reasons.
SWEACn doesn't always appear in the server response where you've
originally recorded it. That being said, it will always be in the
"web_url's" response right before the call where you need it.
Basically, what i'm saying is, move your web_reg_save_param from where
you originally had it recorded to one request prior to where you need
it. This has never failed me so far.
SWC is a strange one... I don't quite understand how the system
updates this value. It adds / subtracts integers like it was
calculated instead of considering as part of a response from the
server (maybe this is solved by the Siebel correlation rules but i
don't use them). Anyways, when you get a "back or refresh error",
first thing you should suspect is the Siebel_SWECount (SWC). Usually,
this will happen after the first iteration. My advice for this one,
stick a web_reg_save_param before the call prior to the problematic
URL. Look in the appropriate server response for the real SWEC value
and put the proper boundaries in the WRSP. Of course, you'll need to
put this code before the problematic URL:
Siebel_SWECount_var = atoi(lr_eval_string("{YOUR_SWEC_PARAM_NAME}"));
lr_save_int(Siebel_SWECount_var, "Siebel_SWECount");
Also, make sure the problematic URL calls a dynamic SWEC not a
hardcoded one.
SWEC={Siebel_SWECount} GOOD!
SWEC=13 BAD!
the native correlation rules over the ones provided by Siebel. Sure
the added rules help you grab more stuff but the correlations are not
always on target either. Also, you end up with so many possible
parameters to choose from it becomes confusing. But thats just me and
this opinion is highly subjective. As a matter of fact, my partner has
the Siebel rules installed and swears by them so yeah... you can try
them and see for yourself :)
To answer a little on your questions:
rowids: The single most important part of a record. You can use it to
retrieve a given record but you will also need it to perform actions
like "delete", "drilldown", "select", etc. You will also need it as a
"reference" when you want to navigate through a record's sub tabs.
This is vulgarized but maybe it'll help shed some light:
SWERowId = rowid to perform the action/method on
SWERowIds = record's parent rowid
SWEACn & SWC:
These gave me a lot of trouble at first but for two different reasons.
SWEACn doesn't always appear in the server response where you've
originally recorded it. That being said, it will always be in the
"web_url's" response right before the call where you need it.
Basically, what i'm saying is, move your web_reg_save_param from where
you originally had it recorded to one request prior to where you need
it. This has never failed me so far.
SWC is a strange one... I don't quite understand how the system
updates this value. It adds / subtracts integers like it was
calculated instead of considering as part of a response from the
server (maybe this is solved by the Siebel correlation rules but i
don't use them). Anyways, when you get a "back or refresh error",
first thing you should suspect is the Siebel_SWECount (SWC). Usually,
this will happen after the first iteration. My advice for this one,
stick a web_reg_save_param before the call prior to the problematic
URL. Look in the appropriate server response for the real SWEC value
and put the proper boundaries in the WRSP. Of course, you'll need to
put this code before the problematic URL:
Siebel_SWECount_var = atoi(lr_eval_string("{YOUR_SWEC_PARAM_NAME}"));
lr_save_int(Siebel_SWECount_var, "Siebel_SWECount");
Also, make sure the problematic URL calls a dynamic SWEC not a
hardcoded one.
SWEC={Siebel_SWECount} GOOD!
SWEC=13 BAD!
