A treasure trove of data and access history! ▽Access history management prototype created in a simple two-hour course using Laravel middleware and Eloquent
Hidden data assets of information system
Regarding the business data (eg, order data, settlement data, quality information data) that is accumulated daily by operating the information system, its utilization is discussed extensively, while the access history of the information system is I don’t hear much about cases where active collection and utilization are progressing.
By accumulating access history, it seems that the information system unit can be used in various ways:
- Control of frequently used functions (➡ Focused improvements to make it easier to use)
- Grasping of functions that are not used often (➡ Support for improving usage, abolition of functions, etc…)
In addition to the functions used, what kind of data is input and what kind of data is output can be used as input/output information at the time of a unit test by logging together. There seems to be a way.
Not accumulating access history may be like draining important data assets (excessive?).
After studying Laravel, I made an “access history management” prototype that can be easily implemented, so I will introduce it as an example.
Overview of “Access history management” prototype
I will introduce only the core part.
Table preparation
Create an “access history” table.
Columns such as “accessor ID” are omitted to make the table a simple structure for study purposes.
Parameters may be blank, so don’t forget to specify nullable()
.
class CreateAccessLogTable extends Migration
{
public function up()
{
Schema::create('access_log', function (Blueprint $table) {
// Serial number
$table->increments('no');
// method (eg GET / POST / PUT etc.)
$table->string('method');
// URI
$table->string('uri');
// parameter (IN)
$table->string('params_in')->nullable();
// Parameter (OUT)
$table->string('params_out')->nullable();
// access date
$table->timestamps();
});
}
}
Creating access record middleware
Let’s create the AccessLogger
middleware to record the following information for all HTTP requests.
- Method
- URI
- Parameter (IN)
- Parameter (OUT)
Note that the access date and time is replaced by the updated_at()
column, which is automatically updated by Laravel, so there is no need to write it.
I felt the aesthetics of Laravel in that the records in the “access history” table could be described with code within 10 lines.
<?php
namespace App\Http\Middleware;
use App\AccessLog;
use Closure;
class AccessLoggerMiddleware
{
public function handle($request, Closure $next)
{
$response = $next($request);
// "access history" information
AccessLog::create([
'method' => $request->method(),
'uri' => $request->path(),
'params_in' => serialize($request->input()),
'params_out' => $response->content(),
]);
return $response;
}
}
Creating access history browsing screen
It is a very rough idea, but almost all the work up to this point (+α) completed the framework for storing access history.
Since it is a big deal, let’s prepare a screen for browsing the contents of the “access history” table.
Overall image
The screen consists of two rows, left and right.
- Left side: Access history information
- Right side: Parameter information
About parameter display
Parameters come in various formats, so don’t worry about how to present them.
For the time being, I will process it so that the character string can be displayed regardless of the parameter format.
- String parameter: apply
htmlspecialchars()
- PHP array parameter: apply
implode()
- JSON parameter: apply
json_encode()
Display this with <input type="text">
in the table, and be careful to add a button to copy it to the clipboard.
#Summary
While thinking with my head, I moved my hands, and in about two hours, I could make something that behaves like that.
It’s also a good thing that I gained a deeper understanding of the technology by leveraging the Laravel knowledge I had just started learning.
I often put in an access history that stores the usage function (or URI information), but I have never created anything that can store and easily browse input/output parameter values. did.
When a user inquires, it is possible to trace what kind of operation was performed with a log with parameter values, because it will help solve problems early, so I think it is a highly practical tool**. ..
It is also useful data as a hint to analyze the system usage tendency with AI and explore the needs of the user department at the timing of system reconstruction.