Introduction to the ABS Framework

When considering the solution design for a business requirement, we usually have a few configuration options at our disposal.

One of the cardinal decisions we make, is wether we choose to build our solution using WF or Script, there is a lot of emphasis put on this decision by the Siebel community.

In my opinion, wether we use WF or Script isnt important, what is important, is the result. The ultimate goal should be to ensure that the build, is maintainable, scalable, and upgradable.

In the comming series, and i'm going to look at the ABS framework, and see wether it meets the above goals.

What is the ABS framework?

The ABS framework is a custom Siebel framework that embodies the following principles

  1. Maintainable
  2. Resuable
  3. Scalable

and it is written in eScript!

Its important to note that, the ABS framework is more than just a library of functions, it is an alternative Siebel framework, with features beyond scripting.

What are the features of the ABS framework?

  1. Centralization of all business logic
  2. Reduces scripting
  3. Reduces development time and implementation
  4. Superior Logging and Tracing
  5. Ready made eScript library
  6. Abstraction of Siebel Objects

There is no public documentation on the ABS framework, and what we currently know, are mainly from word of mouth or blogs across the Internet. There are still a lot of questions and speculation about the ABS Framework.

With courtesy from the ATI framework (which is extended from ABS), i have a unique opportunity to explore the framework from the source code level.

In the next series of articles, i will endeavour to reveal its features and discover the answers to all the questions we've been asking.


10 comments:

  1. Interesting stuff...Look forward to it.

    ReplyDelete
  2. this detail was left out intentionally. there is more background which will be provided in later articles.

    ReplyDelete
  3. Good to know I will wait for this.

    ReplyDelete
  4. Hi Can't we use custom business services instead of writing prototypes which accepts same number of parameters as we are passing while calling prototypes...

    ReplyDelete
  5. Hi Rahul,

    BSs and protoypes both have their places. BSs need to be instantiated and referenced to work. Input property sets are also restricted to text types. You are adding more overhead, and making the code more cluttered, compared to a protoype solution.

    Jason

    ReplyDelete

Comments are open to all, please make it constructive.