Aelum Consulting

  Remote tables are another component that permits you to characterize a table inside ServiceNow. It also helps to interface it to an outer information source. ServiceNow  gets its records from running a related content against the outside information source. These records live in memory, which implies they are clean after you leave the rundown/structure. Before we go in detail with the remote tables. Let’s start with : Why do we require remote tables? Let’s try to see some usual challenges in data on Service-Now Complications to collaborate data distributed among various tables interrelated. Usually we create a table, use Business Rules or scheduled jobs to maintain this data. This approach has one big con which is small changes require modifications on multiple configurations such as data for an additional column. Handling of rarely utilized data from external sources. Creating a table use schedule jobs to maintain these data and purge them on a regular basis or requirement. Con on t

  GlideTable Hierarchy  is a ServiceNow Server scoped API which provides information about the Table hierarchy and relationships. We have  TableUtils  API which can be used to retrieve the hierarchy of tables in ServiceNow. So How actually the Table Hierarchy API is useful? TableUtils  is limited to the global scope in  ServiceNow  and it cannot be accessed from scoped application. So there is either of ways to achieve this solution: Copy  TableUtils  inside the scoped application. writing logic for GlideRecord the “sys_db_object” table. This solution implementation might take some additional effort for a developer. So here  TableHierarchy  API can be very useful to bring our efforts down and easy in implementation. To get the hierarchy of any table in scoped applications. The below methods will be useful. Method Summary: In this Blog, We will drive through a few methods of this API with reference to the  CMDB  table hierarchy. For that we can use this API as follows: API Definition: g

  Understanding LDAP in Laravel Application LDAP (Lightweight Directory Access Protocol) is a directory services protocol that is used for interacting with directory services. One of the examples of directory services is Active Directory (AD) which is Microsoft’s proprietary directory service used to manage and store information about the devices, users, objects within an organization’s network. So, here we will understand how to do LDAP connectivity in laravel to authenticate users in the active directory. Easy steps to setup LDAP in Laravel Application Step 01:  Install the third-party LDAP package adldap2 in your laravel application using the below command. composer require adldap2/adldap2-laravel Step 02:  Publish the installed package using the below command. PHP artisan vendor:publish –provider=”Adldap\Laravel\AdldapServiceProvider” Step 03:  Most importantly, uncomment the dll for LDAP from the php.ini file first otherwise it will throw an error. Step 04:  Configure the followin

  Agenda : In many real-time applications, at times we have to limit the total number of users to a limit. Ex: while booking movie tickets, or gaming events, and so on.  The problem at hand is to limit the total number of users registered in such scenarios.  We will consider  virtual cricket match application registration  for the use case.  Background of the Scenario Following is a walkthrough of the actions in the picture: Users register themselves. Users see a list of different cricket matches that will start within an hour timeframe. The timer is running in the background. The User clicks on a cricket match from the list. Now the user has to create a virtual team of cricket players to play the match.  The User clicks on a cricket match from the list. Now the user has to create a virtual team of cricket players to play the match.  As soon as the team is created a list of contests appears. Users now have to join any contest. Some amount will be deducted from the wallet depending on t