Stephen Smith's Blog

All things Sage ERP…

Posts Tagged ‘Sage

Drilldown in Sage 300 ERP

with one comment

Introduction

Much accounting detail is entered in one application and passed on to another for recording. Drilldown is the ability to reverse the audit trail and display, application by application, the document back to its original entry into the Sage 300 ERP system. For example, in Sage 300 General Ledger (G/L), you can drilldown from General Ledger Transaction History to the Journal Entry, from the Journal Entry to the originating transaction in Accounts Receivable, and from the Invoice, Credit Note, or Debit Note, to the originating transaction in Order Entry.

The way this works is a bit cryptic in Sage 300 ERP’s database and this blog article will attempt to explain some of the internal workings so that developers and customizers who want to use this data for other purposes can hopefully figure out how to interpret it.

The documentation for the full drilldown infrastructure for third party developers is contained in Appendix L of the SDK’s Programming Guide.

drilldwn

Drilldown Database Fields

The drilldown fields in a document provide a link to the application that created the document. They are done in a generic way so any application (Sage or third party) can provide this information and their screens can be drilled down to. As a result the fields are fairly generic and it’s up to the drilldown target to provide what it needs when it creates the document. There are three fields, one is the source application (our usual two character application id like AP), then a drill down type (each application may have several document types like invoices or receipts), and last there is a generic link field which is a large number where the application packs in whatever it needs to do a link.

For example you can drill down from G/L Journal Entry back to the application that created the Journal. In the GLJEH table there are three fields: DRILAPP, DRILSRCTY, DRILLDWNLK. Suppose P/O creates a Journal Entry, it might populate DRILAPP with “PO”, DRILSRCTY with 3 (for Receipt) then DRILLDWNLK with 1740 (where 1740 is a link to PORCPH1.RCPHSEQ).

This is rather cryptic since these fields are meant to be internal to the application that will be drilled down to. But suppose you want to use these fields for other purpose. Here I’ll give a few examples of how Sage applications use these, which should help for many cases. Plus they will give an indication on how these are built so you can reverse engineer other cases.

Here are the ones used for I/C, O/E and P/O. These are pretty straight forward due to the way data is indexed in these applications. Here are the various types and links used in these applications.

IC:

Receipt: 1: ICREEH.DOCUNIQ
Shipment: 2: ICSHEH.DOCUNIQ
Adjustment: 3: ICADEH.DOCUNIQ
Transfer: 4: ICTREH.DOCUNIQ
Assembly: 5: ICASEN.DOCUNIQ

OE:

Shipment: 3: OESHIH.SHIUNIQ
Invoice: 1: OEINVH.DAYENDNUM
Credit and Debit Note: 2: OECRDH.CRDUNIQ

PO:

Receipt: 3: PORCPH1.RCPHSEQ
Invoice: 5: POINVH1.INVHSEQ
Return: 4: PORETH1.RETHSEQ
Credit Note: 6: POCRNH1.CRNHSEQ
Debit Note: 7: POCRNH1.CRNHSEQ

A/R and A/P are a bit more difficult. Here they have to pack quite a bit of information into that field. A 10-byte BCD can hold up to 18 digits. Into this we want to pack the Posting Sequence Number, Batch Number and Entry Number. The way this works, the first digit is the size of the Posting Sequence Number, then the second digit is the size of the Batch Number. Then you have the Posting Sequence Number, then the Batch Number then the left over is the Entry Number. Since the first two digits are used for sizes, the sum of the lengths of the Posting Sequence Number, Batch Number and Entry Number must be less than or equal to 16.

For instance if the DRILLDWNLK is 222765000000000001 then the length of the Posting Sequence Number is 2 as is the length of the Batch Number. The Posting Sequence Number is 27, the Batch Number is 65 and the Entry is 1.

Drilldown View

Knowing the raw format is fine for some applications. But if you are operating in an environment with access to the Sage 300 Business Logic then you can call the application’s View to interpret this value for you and give it in the format of a UI to run and the parameters to pass it, to get the correct information displayed.

Here we will write a small .Net application that uses the Sage 300 API .Net API to process through the drill down information in the G/L Journal Header and process the A/P drill down information. You can find the project here, it is the Drilldown one.

Each application that supports drilldown has such a view. It is defined in its xx.ini file (in this case ap.ini) in the [setup] section there will be a DrillDownView=aannnn entry which specifies the drill down view (in this case AP0062). In the sample program, I just hard code the View and leave it as an exercise to the reader to generalize and load these from the .INI file.

Basically you use this view by setting the drill down type and link and then calling Process(). This then populates the other fields. This gives you a status field of whether you can drill down on this, a roto id of a UI to run and the parameters to pass the UI. Note that UI parameters are separated by line breaks.

So in this case we run the application we get lines specifying the drill down info followed by the drill down View’s interpretation of it. For instance:

Drill down info in GLJEH: AP 0 223055000000000001

UI Information to run for this: AP2100 MODE=1\nBATCH=55\nENTRY=1

Here is the main part of the code that processes this:

// Cycle through all of GLJEH and printout all the drill down information
 while (true == glJEH.Fetch(false))
 {
        string drillSrce, drillLnk, rotoid, parameters, drillkey, drillInfo;
        int drillType;
        drillSrce = glJEH.Fields.FieldByName("DRILAPP").Value.ToString();
        drillType = Convert.ToInt32(glJEH.Fields.FieldByName("DRILSRCTY").Value.ToString());
        drillLnk = glJEH.Fields.FieldByName("DRILLDWNLK").Value.ToString();
        Console.WriteLine("Drilldown: " + drillSrce + " " + drillType + " " + drillLnk);
        if ( drillSrce.Equals("AP") )
        {
                 apDrill.Fields.FieldByName("SRCETYPE").SetValue(drillType, false);
                 apDrill.Fields.FieldByName("DRILLDWNLK").SetValue(drillLnk, false);
                  apDrill.Process();
                  drillInfo = apDrill.Fields.FieldByName("DRILLTYPE").Value.ToString();
                  rotoid = apDrill.Fields.FieldByName("ROTOID").Value.ToString();
                 parameters = apDrill.Fields.FieldByName("PARAMETERS").Value.ToString();
                 drillkey = apDrill.Fields.FieldByName("DRILLKEY").Value.ToString();
                Console.WriteLine(drillInfo + " " + rotoid + " " + parameters + " " + drillkey);
         }
  }

Summary

Drill down is a useful feature in Sage 300 ERP and hopefully this information helps people leverage the infrastructure for some new interesting customizations and integrations.

Written by smist08

February 27, 2015 at 8:48 am

On Calculating Dashboards

with 4 comments

Introduction

Most modern business applications have some sort of dashboard that displays a number of KPIs when you first sign-in. For instance here area a couple of KPIs from Sage 300 ERP:

s300portal

To be useful, these KPIs can involve quite sophisticated calculations to display relevant information. However users need to have their home page start extremely quickly so they can get on with their work. This article describes various techniques to calculate and present this information quickly. Starting with easy straight forward approaches progressing into more sophisticated methods utilizing the power of the cloud.

Simple Approach

The simplest way to program such a KPI is to leverage any existing calculations (or business logic) in the application and use that to retrieve the data. In the case of Sage 300 ERP this involves using the business logic Views which we’ve discussed in quite a few blog posts.

This usually gives a quick way to get something working, but often doesn’t exactly match what is required or is a bit slow to display.

Optimized Approach

Last week, we looked a bit at using the Sage 300 ERP .Net API to do a general SQL Query which could be used to optimize calculating a KPI. In this case you could construct a SQL statement to do exactly what you need and optimize it nicely in SQL Management Studio. In some cases this will be much faster than the Sage 300 Views, in some cases it won’t be if the business logic already does this.

Incremental Approach

Often KPIs are just sums or consolidations of lots of data. You cloud maintain the KPIs as you generate the data. So for each new batch posted, the KPI values are stored in another table and incrementally updated. Often KPIs are generated from statistics that are maintained as other operations are run. This is a good optimization approach but lacks flexibility since to customize it you need to change the business logic. Plus the more data that needs to be updated during posting will slow down the posting process, annoying the person doing posting.

Caching

As a next step you could cache the calculated values, so if the user has already executed a KPI once today then cache the value, so if they exit the program and then re-enter it then the KPIs can be quickly drawn by retrieving the values from the cache with no SQL or other calculations required.

For a web application like the Sage 300 Portal, rather than cache the data retrieved from the database or calculated, usually it would cache the JSON or XML data returned from the web service call that asked for the data. So when the web page for the KPI makes a request to the server, the cache just gives it the data to return to the browser, no formatting, calculation or anything else required.

Often if the cache lasts one day that is good enough, there can be a manual refresh button to get it recalculated, but mostly the user just needs to wait for the calculation once a day and then things are instant.

The Cloud

In the cloud, it’s quite easy to create virtual machines to run computations for you. It’s also quite easy to take advantage of various Big Data databases for storing large amounts of data (these are often referred to as NoSQL databases).

Cloud Approach

Cloud applications usually don’t calculate things when you ask for them. For instance when you do a Google search, it doesn’t really search anything, it looks up your search in a Big Data database, basically doing a database read that returns the HTML to display. The searching is actually done in the background by agents (or spiders) that are always running, searching the web and adding the data to the Big Data database.

In the cloud it’s pretty common to have lots or running processes that are just calculating things on the off chance someone will ask for it.

So in the above example there could be a process running at night the checks each user’s KPI settings and performs the calculation putting the data in the cache, so that the user gets the data instantly first thing in the morning, and unless they hit the manual refresh button, never wait for any calculations to be performed.

That helps things quite a bit but the user still needs to wait for a SQL query or calculation if they change the settings for their KPI or hits the manual refresh button. A sample KPI configuration screen from Sage 300 is:

s300portalconfig

As you can see from this example there are quite a few different configuration options, but in some sense not a truly rediculous number.

I’ve mentioned “Big Data” a few times in this article but so far all we’ve talked about is caching a few bits of data, but really the number of these being cached won’t be a very large number. Now suppose we calculate all possible values for this setup screen. Use the distributed computing powe of the cloud to do the calculations and then store all the possibilities in a “Big Data” database. This is much larger than we talked about previously, but we are barely scratching the surface of what these databases are meant to handle.

We are using the core functionality of the Big Data database, we are doing reads based on the inputs and returning the JSON (or XML or HTML) to display in the widget. As our cloud grows and we add more and more customers, the number of these will increase greatly, but  the Big Data database will just scale out using more and more servers to perform the work based on the current workload.

Then you can let these run all the time, so the values keep getting updated and even the refresh button (if you bother to keep it), will just get a new value from the Big Data cache. So a SQL query or other calculation is never triggered by a user action ever.

This is the spider/read model. Another would be to sync the application’s SQL database to a NoSQL database that then calculates the KPIs using MapReduce calculations. But this approach tends to be quite inflexible. However it can work if the sync’ing and transformation of the database solves a large number of queries at once. Creating such a database in a manner than the MapReduce queries all run fast is a rather nontrivial undertaking and runs the risk that in the end the MapReduces take too long to calculate. The two methods could also be combined, phase one would be to sync into the NoSQL database, then the spider processes calculate the caches doing the KPI calculations as MapReduce jobs.

This is all a lot of work and a lot of setup, but once in the cloud the customer doesn’t need to worry about any of this, just the vendor and with modern PaaS deployments this can all be automated and scaled easily once its setup correctly (which is a fair amount of work).

Summary

There are lots of techniques to produce/calculate business KPIs quickly. All these techniques are great, but if you have a cloud solution and you want its opening page to display in less that a second, you need more. This is where the power of the cloud can come in to pre-calculate everything so you never need to wait.

Written by smist08

February 14, 2015 at 7:25 pm

The Sage 300 SDLC

leave a comment »

Introduction

A lot of my blog posts are to answer questions that I frequently receive. Then I have a ready answer of a blog posting link, or perhaps people read my blog and it saves me receiving an e-mail. This blog posting is along the same lines as I get asked quite frequently about our SDLC (Software Development Lifecycle). Usually this is in regards to someone trying to fill out a giant RFP full of questions that are mostly irrelevant to purchasing ERP software.

I covered various aspects of our development process in other blog posting which I’ll refer to here. Plus our process is always evolving as we learn from our experiences and try to improve. What I’m writing about here is specifically what the development team for Sage 300 ERP does, but a lot of it is also used by other Sage teams on other projects. There are always slight variations as the different teams do have their own preferences and as long as they follow the general standards that’s ok.

Within R&D we use the Agile Development Methodology, but R&D exists within a larger context within Sage, much of which doesn’t use Agile frameworks. As a result our Agile development has to fit somewhat within a larger non-Agile system that tracks and coordinates the various projects going on around Sage. This is to ensure all departments know what is going on and can plan accordingly.

Not-Agile

We have a general PMO department that tracks all the various projects. It coordinates getting approval for projects, determining release criteria and coordinating all the various departments such as Marketing, Product Management, IS, etc. So they can do their pieces at the appropriate time.

Initial product ideas come from our Innovation Process, but before converting an innovation idea into a larger development effort there is usually some POC work and some initial rough estimates that then lead to a project kickoff process where an initial business plan, along with an initial project plan are presented and either approved or rejected.

The project is then tracked by PMO as it goes through development and then at the end when the Agile part of the development is done, there is a release certification meeting where all the stakeholders get together that the solution is ready for customers. This includes that the software is ready and of a high quality, but also that support is ready, training material is available, back end systems are setup to take orders, marketing is ready and all the other pieces that go into a product launch.

Web_SDLC_GoodPMO

Also at this time we run a final regression to ensure that everything is working correctly. Generally this is only a couple of weeks as a sanity check that the Agile process below worked correctly.

Before making the product available to all customers, we first spend a few months in a controlled release with a handful of live customers to ensure everything works well for them. This not only tests the software, but their ability to be on-boarded, supported and trained. After this has proceeded successfully then the product is made available for everyone.

Some of these reasons for this non-Agile framework is that a number of parts of our organization having adopted Agile yet and eventually they will need to if we are to have truly effective cloud based products. The other reason that I blogged about here, is the need to coordinate many disparate teams working on different parts of a larger solution.

Agile

Within R&D we use the Agile Development Methodology. I’ve blogged about Agile development a number of times: here, here, here, here and here.

We’ve been using Agile programming for a number of years now. We use 2 week sprints, have sprint planning, maintain a backlog, have daily standups, sprint demos, sprint retrospectives and all the other aspects of Agile. We use VersionOne to manage our projects. In Agile you execute the backlog story by story and have very tight rules on what it means for a story to be “done”. This way as each story is completed, it is fully tested, documented and ready for use. The important thing here is to not build up a large list of defects that need to be fixed near the end of the project. Basically when the last story is finished (done) then the product should be ready to put in customer’s hands.

agile

The doneness criteria vary a bit by Agile team, but here are the doneness criteria for a team on one of our current projects:

  • All tasks items in a backlog story have a closed status
  • The code builds successfully without compiler errors and warnings and without ReSharper issues
  • The code is deployed to test environment successfully
  • The code is checked into the correct repository and branch
  • The code conforms to Sage Branding Guidelines.
  • The code performs to performance standards
  • The code is reviewed for applicable use of all documented standards.
  • The code is refactored and reviewed for good OOP implementation
  • The code conforms to UX wireframes, design and CSS guidelines.
  • Code coverage minimum percentage is 70% with a target of +90%
  • The UI displays correctly in all supported browsers (IE, Safari, Firefox, Chrome)
  • Unit tests are included and run successfully
  • Automation tests are included and run successfully in test environment
  • The environment has not been corrupted (database, etc.)
  • The QA and QA Review tasks are included and complete
  • Reviewed and accepted by the Product Owner
  • Implement and document any build and/or deployment changes
  • Knowledge Transfer Activities (wiki updated, code walkthrough, group code review, etc.)
  • Remaining hours for tasks are set to zero and the backlog item is closed

 

Ensuring stories are done is the key to a well-run Agile process, probably more important than a well-structured prioritized backlog.

As part of developing for the cloud, we want to release fairly regularly and can’t afford long manual regression tests. As a result we have a lot of emphasis on Unit Tests and Automated tests, such as those blogged here.

Similarly branching strategy, source code management, build management and continuous integration are also important parts of this process.

Summary

This was a quick overview of our Sage 300 SDLC. With any big project there are always a lot of moving parts and these have to be tracked accurately and reliably. Agile doesn’t mean that we don’t have deadlines or firm requirements. It does mean that we develop the most important things first and build quality in from the very start.

Bangalore Travel Blog Part 1

with 3 comments

Introduction

I’m currently travelling to Bangalore, India to visit a large number of off-shore team members we work with on our projects. So for something different, I thought I’d try travel-blogging. I’ll be writing this blog as I go along and then periodically post my progress. This is my second trip to India, I visited Chennai back in 2008 for ten days.

Sage is partnered with several Indian companies to provide extra capacity for our projects. For this trip I’m visiting Sonata which has teams participating in several important Sage projects. I blogged previously on accelerating projects, which was really talking about our adding capacity through additional teams at Sonata. It’s great to have extra capacity and the ability to get more done, but it’s also a big challenge keeping all the teams moving in the same direction and continuously removing roadblocks and bottlenecks. Our goal is to treat the Sonata teams as if they were regular Sage agile teams with full access to all Sage resources like source control and other internal systems. To make this process work many Sonata folk visit our Richmond office and we have several staff visiting Bangalore. This is my turn.

Indian Visa Process

To back up a bit, travelling to India is a bit more difficult than other places due to the Visa process. To do this I needed letters from Sage and from Sonata giving my reasons for travel and that I’m still being paid by a Canadian company. Then you need to fill out and extremely long on-line visa application that includes detailed questions on yourself, your spouse and your parents. Gathering all the data for this form took several days, and when you save this form, it is quite buggy retrieving what you had before, so you need to check it closely. You also need a US sized passport photo and a Canadian passport with 1 year left (since I wanted a 1 year multi-entry visa). With all this you make an appointment with the company (BLS) that processes the visas. The earliest I could book was 1 week later. Then you show up for your appointment and they double check all your papers and take the rather large fee ($200). They take all this as well as your passport and promise to process it in 7 business days. Basically at this point they give it all to the Indian consulate for processing. Fortunately this all went fine and 5 days later their website said my passport was ready for pickup. Generally of all the countries I’ve visited, this is by far the hardest visa process.

Shots

If you don’t travel much, you should go to a travel clinic to get the right shots when visiting India. I travel quite a bit and all my shots are up to date. The first time I went to India, I needed to get 5 injections. I do recommend taking something like Dukoral since I’ve never had any tummy troubles when I’ve taken this ahead of a trip. Malaria pills may or may not be required depending on where you are going.

It’s a Long Way

I travelled to Bangalore via Hong Kong. It’s a 14 hour flight to Hong Kong and then a 6 hour flight on to Bangalore. Generally the best way to endure a long flight is to sleep through it. The Hong Kong flight left at 2:30pm, so I wasn’t sleepy until near end. By the time I was on the Bangalore flight I was so tired I slept through most of the flight. For some reason all international flights in and out of Bangalore arrive and leave between midnight and 4am. When you arrive you don’t really care what time it is just want to get to the hotel and sleep, so make sure you book for a day earlier, so you don’t need to then wait till 2pm to check in.

Managing in Bangalore

Some Indian cities can be quite hard to navigate. But Bangalore is fairly easy. You do need know how to cross the streets (i.e. make eye contact and walk slowly across the traffic, which will flow around you). If you are worried about having to eat lots of extremely hot Indian food, then don’t worry there are many good restaurants from other cultures like Italian or Mexican. Plus generally I don’t find the Indian food that hot here (perhaps it’s toned down for the tourists). I find the level of English was quite good and haven’t had any problems communicating.

Getting directions and finding your way around isn’t that hard and the area around my hotel (in the downtown old part of the city) seems quite safe. There are quite a few parks around and you can see quite a bit just walking around.

IMG_2864

The office is 10km away and parts of the journey can be quite congested, but I find the traffic here to be better than in Chennai, Bangkok or Ho Chi Minh City. They are building a new elevated metro system which is causing quite a bit of road disruption along the way, but they seem to keep traffic flowing.

Work Environments

The office building is located in the Global Village Tech Park outside the city. There are quite a few tech companies located here including Sonata, MindTree, Accenture, HP and Texas Instruments. The office environment I’m at is quite nice. The building is modern and the work environment is quite pleasant. It uses an open office concept and provides a nice productive team environment.

IMG_0701

Since this is India the company parking is quite different than what you would expect in North America. To maneuver quickly through traffic, two wheels is the way to go. If everyone using motorbikes was to switch to cars it would be total grid lock here.

IMG_0703

Conclusion

This ends part 1 of my travel to India. I’m now here and settled in. Getting here is half the battle, now it’s time to get some productive work done.

Written by smist08

November 4, 2014 at 12:28 pm

Posted in Business

Tagged with , , , ,

How to Run Customized Sage 300 Screens from Sage CRM

with 2 comments

Introduction

From the Sage 300 ERP to Sage CRM integration there is the ability to run a number of Sage 300 ERP screens. These are the older VB screens being run as ActiveX controls from the IE browser. Not to be confused with the newer Quote to Order web based screens. A common request is how to customize these screens to you run the customized screen from Sage CRM rather than the base screen.

This blog posting covers how to run customized screens from Sage CRM. As a bonus, as part of this it also shows how to wrap a Sage 300 screen, so that it handles version updates seamlessly and doesn’t require you to re-compile your solution when we release a new version of the base screen. As a result this mechanism requires you use VB to wrap the base control for deployment. The ideas presented here probably can be ported to other programming systems, but it may not be easy.

A sample project that wraps Order Entry is located on Google Drive here. This project will be used for most of the examples in the document, so feel free to load it up and follow along.  In order to view the wrapper, simply unzip the file, and open up the CRMOEOrderUI.vbp.

Create the Wrapper

The following instructions will show the basic steps on how to create a Sage 300 UI Browser Wrapper.  The wrapper can then be referenced by an ASP page. There should be a constant interaction between the UI, the wrapper, and the ASP page (ie. UI calls UI_OnUIAppOpened in the wrapper, the wrapper raises the UIWasUnLoaded event to the ASP page, and the ASP page in turn catches the event, and closes the window containing the wrapper (and attached Accpac UI).

Instructions

1. Open up Visual Basic and select a new Active X Control. Click Open.

custcrm1

2. Go to Project/ References, and select ACCPAC COM API Object, ACCPAC Data Source Control, ACCPAC Signon Manager, VB IObjectSafety Interface, ACCPAC Application Installer, and ACCPAC Session Manager.

custcrm2

3. The project name determines the name of the wrapper (OCX).  In this case, the wrapper name will be “eCRMOEOrderUI”.

4. The name that you give the UserControl should be descriptive of what is contained on it.  In this case, give the UserControl the same name as the Accpac UI that is wrapped (in this case, OEOrderUI).

custcrm3

5. When you are coding refer to the Accpac UI as “UserControl” (ie. UserControl.Width, UserControl.height).

6. We use the VBControlExtender to wrap the Order Entry OCX control dynamically when UserControl_Show is called (see code for UserControl_Show accompanied with this document). When referencing elements and methods within the Order Entry OCX control you would use ctlDynamic.object. The control is installed and opened using the AccpacOcxRegHelper.CLS which makes entries in to the registry that allows the VBControlExtender to reference the control by name as opposed to CLSID which is returned from Roto.

custcrm4

7. Now you are ready to begin writing the code that will catch the events thrown by the Accpac UI, and raise your own events to the ASP that will contain your wrapper.

8. Go into your code view and begin instantiating your events, objects, and variables.

9. Begin by declaring your objects that are going to handle events thrown by the AccpacDataSource controls in the related Accpac OCX controls.  In this case, event handlers of the AccpacOE1100 class are being declared so that they can detect the events thrown by the class.

custcrm5

10. Next, declare the events that you will want to raise to the ASP page.

custcrm6

11. Declare your public variables

custcrm7

12. Declare your remaining variables.  In this case, mSignonMgr is going to be used to sign on the Accpac UI with the signon manager so that the signon screen does not keep popping up every time that the UI is loaded.  mlSignonID is going to be the signon ID.

custcrm8

13. Outline your functions that will be called by the ASP Page.  In this case, the ASP page will give the values that are to be used to populate the UI, or to insert the customer ID into the UI’s customer field for a new customer quote.

custcrm9
14. Next, list out the events that can be called by the UI AccpacDataSources.  In the screenshot below, you can see that the wrapper is checking the eReason variable being passed, and depending on what eReason is being passed, a different event will be raised to the ASP page (AddNew, Delete etc) in the RaiseEventEX sub.

custcrm10
custcrm11
custcrm12

 

15. Other functions are also called by the Accpac UI. The wrapper will be notified of these events through ctlDynamic_ObjectEvent (see below). Once the UI has opened ctlDynamic_ObjectEvent is called with an event name of  “OnUIAppOpened” and a private sub UI_OnUIAppOpened is called and objects in the wrapper are initialized, and the UIWasLoaded event is raised to the ASP page notifying it that the UI has been opened.
custcrm13
custcrm14

16. Finally, define the Get properties that are available to the ASP page so that it can resize its windows when the UI has been loaded onto the ASP page.  In this case, the ASP page will resize its windows to be the same width, height, and unit of measurement as the UI.

custcrm15

17. Now, you have successfully entered all the code that the wrapper will use to receive the function calls from the UI, as well as raise the events to the ASP page.

Customize the Sage CRM ASP Page

You now have a wrapped OCX now you can follow the ASP page in Sage CRM (for example, OE_OrderUI.asp as follows) to call your customized OCX.

http://bcr512115/CRM/CustomPages/Accpac/OE_OrderUI.asp?SID=15427674933819&Key0=1&Key1=44&Key2=58&F=Accpac/OE_Orders.asp&J=Accpac/OE_OrderUI.asp&QUOTENUM=ORD000000000076&CUSTID=AA20130815&DATABASE=SAMINC

Then it will open the OE Order Entry screen for order ORD000000000076.

In OE_OrderUI.asp file, it has following code:

 

<!–

eCRMOEOrderUI raises the following events:

UIWasLoaded(), UIWasUnLoaded(), AddNew(), Delete(), Update(), FieldChange(), Init(), Read(), Fetch()

eCRMOEOrderUI exposes the following Properties:

UIWidth(Read Only), UIHeight(Read Only), TwipsPerPixelX(Read Only), TwipsPerPixelX(Read Only)

eCRMOEOrderUI exposes the following Functions:

PopulateUI(OrderID As String, CustomerID As String);

CreateNewQuote(CustomerID As String);

–>

<SCRIPT for=”eCRMOEOrderUI” Event=”UIWasLoaded()”>

var width  = eCRMOEOrderUI.UIWidth / eCRMOEOrderUI.TwipsPerPixelX;

var height = eCRMOEOrderUI.UIHeight / eCRMOEOrderUI.TwipsPerPixelY;

if ((BrowserDetect.browser==”Explorer”) && (BrowserDetect.version >= 7))

{

width  += 35;

height += 130;

}

else

{

width  += 35;

height += 100;

}

var left = (screen.width – width) / 2;

var top = (screen.height – height) / 2;

window.resizeTo(width, height);

window.moveTo(left,top);

PopulateUI(<%=EnESCDocNum%>, <%=EnESCCustomer%>);

width  = eCRMOEOrderUI.UIWidth  / eCRMOEOrderUI.TwipsPerPixelX;

height = eCRMOEOrderUI.UIHeight / eCRMOEOrderUI.TwipsPerPixelY;

BorderWidth  = ClientWidth()  – width;

BorderHeight = ClientHeight() – height;

bLoaded = true;

resize();

</SCRIPT>

Summary

Hopefully you find this helpful in customizing Sage 300 ERP screens. Even if you don’t run them from Sage CRM, not having to re-build them for each Product Update can save you some time.

Written by smist08

October 11, 2014 at 4:14 pm

Problems with Branching by Feature

with 3 comments

Introduction

Back in January I wrote a blog on Branching by Feature. In this article I want to talk about some problems with branching by feature as well as talk about some other approaches. We’ve been doing branching by feature since a bit before the previous article was written and although some things are working out, there are definitely some disadvantages.

nobranch

Becoming Overly Cautious

The idea of branching by feature is that features aren’t committed into the trunk until they are complete and fully tested. This sounds great, but it leads to some bad behaviors. People get overly cautious about merging their feature back into the trunk. People want to have a perfect merge and just keep delaying it and delaying it. Further the people using the trunk tend to resist merges and keep delaying them asking for more testing or more reviews.

This then leads to all the features being off on separate branches. But what if you are doing something that requires two of these features? You have no way to get them together. Then you have build servers continuously building all these branches, automated testing servers testing them and various other infrastructure being tied up.

Lack of Continuous Integration

To me the main drawback of branch by feature is a lack of continuous integration. Any bad interactions by the outstanding features are not found until much later. A lot of times when these problems are found, people claim it’s due to a lack of testing on the branch and that it was merged too early. But generally these problems couldn’t be discovered until the merge happens.

I tend to find that merge by feature just prolongs integration testing so long that a lot of serious problems are found so much later. Generally the longer between when a bug is introduced and when it’s discovered makes fixing it that much harder and more disruptive. If things are left too long then people have moved on to other projects and don’t like the distraction of going back.

Reducing Merge Hell

Another problem is that the longer things remain on branches, the more work it is to merge them back into the trunk. You can minimize this by continuously merging the trunk back into your branch. But then you have the overhead of continuously managing any conflicts. Plus there is a lot of room for error in this process. Every time you are resolving conflicts in a merge, you have the possibility of making a mistake and erasing someone else’s changes or introducing a bug.

This can lead to an extreme case of having to resolve hundreds of merge conflicts which always leads to errors and worse some pretty extreme conflicts between people or teams that have messed up each other’s code.

Multiple Repositories

For an ERP package like Sage 300, they are composed of many modules like G/L, A/P, A/R, I/C, O/E, P/O, etc. We can source control the whole thing in one repository. This has the advantage that you get everything you need by extracting everything in the one repository. This can be quite convenient. However when you create branches when you merge them back in you do run the risk of conflicting with things that you didn’t expect. Often people just push those conflicts they don’t understand with their own changes. This usually then overwrites someone else’s work.

Currently we have everything together in one big repository, but we are going to break it up into separate repositories, one for each Accounting Module, one for System Manager, one for language translated strings, one for documentation, etc. This way we reduce the number of branches we need and we also reduce the danger of affecting things on too global a scale.

Reducing the number of branches greatly reduces the amount of complexity in the whole process. It also simplifies the process of merging features into the trunk.

This does mean there may be features that can’t be committed atomically as one transaction, it will require two commits in two separate repositories. However we feel that keeping down the scope of the commits is more important than strictly maintaining this atomicity.

You could do your branches at a lower level in the source code tree, but then if you find you need something elsewhere, it’s a fair bit of work to re-branch. This generally leads to people just including everything in their branch which then leads to all the merge problems.

Merge to Trunk Quicker

We are also working to get the different groups and teams to merge features back into trunk much quicker. We make it clear that we do expect to find problems, but that we want to find these earlier and have no expectation that all problems be found and fixed on feature branches. This way we can run the main full set of automated tests off of trunk and don’t need farms of automated test machines testing every branch.

Also for the consumers of these features, they will be all together quicker for people to use off the main builds. This way you won’t need to install multiple branch build to test multiple features.

Summary

As we move more and more into a cloud mode of software delivery, major releases become a thing of the past. In fact for cloud services we don’t really talk about releases anymore. We really just have a live service that is being continuously updated. To do this we need a good continuous delivery infrastructure and a reliable mechanism to develop individual features and merge them to trunk for immediate integration, full automated testing and then deployment to the live cloud service.

As we’ve been on this journey we keep tweaking our branching and build procedures to achieve this goal. Our first branching strategy was progress, but still led to a lot of problems that we are addressing with this new strategy.

Written by smist08

October 4, 2014 at 6:38 pm

Follow

Get every new post delivered to your Inbox.

Join 288 other followers